Health IT Standards Committee: Privacy & Security group present IFR language, EHR module concerns

Twitter icon
Facebook icon
LinkedIn icon
e-mail icon
Google icon

During the Health IT Standards Committee meeting on Feb. 24 in Washington, D.C., the Privacy & Security Workgroup sought to gather comments on proposed recommendations on an initial set of standards, implementation specifications and certification criteria for EHRs for the interim final rule (IFR) of meaningful use.

Presented by Privacy and Security Chair Dixie Baker, senior vice president and technical fellow at Science Applications, a number of concerns and recommendations were outlined over the certification of EHR modules, auditing, integrity, authentication, encryption criterion and standards, accounting of disclosures, consumer access and transport standards within the IFR.

Among the main concerns were whether modules that meet a security criterion but provide no health functions could be certified as an “EHR module” and could a module that meets an EHR criterion, but neither provides nor calls any security services be certified, said Baker.

“Then as a group we thought that if every EHR module provides its own security service, then security protections are going to be fragmented across the organization and it will be impossible to have an enterprise-level security policy enforcement,” said Baker.

“Our recommendation is that the privacy and security criteria be made addressable for every EHR module submitted for certification in the same sense that the implementation specifications for HIPAA are addressable,” said Baker.

“There was a lot of discussion in the language around consumer access and what access will be for consumers,” said Steve Findlay, co-chair, senior health policy analyst at Yonkers, N.Y.-based Consumers Union. “’Online access to their clinical information’ is unclear and the language is inconsistent with the meaningful use objective: ‘Provide patients with timely electronic access to health information,'" said Findlay.

Among language concerns, Findlay noted that:

  • “Online access” could be interpreted as “real time” access;
  • “Online access” may not meet the HIPAA/ American Recovery and Reinvestment Act (ARRA) of 2009 requirement for “electronic copy”;
  • The language is unclear whether “electronic copy” should be human or machine interpretable, or possibly both; and
  • It’s unclear how to measure “meaningful usability” for the consumer.

For recommendations, the workgroup suggested the IFR:

  • Be revised to read: “Enable a user to provide customers with electronic access to their health information, including, at a minimum, lab test results, problem list, medication list, medication allergy list, immunization and procedures and to provide a copy of the consumer’s personal health information in electronic format;"
  • Establish as a priority for 2013 the specification of messaging and vocabulary standards for sending/transferring the electronic records to personal health record vendors; and
  • Publish guidance for developers and eligible professionals and hospitals on how to provide consumers timely electronic access to their health information.

The auditing concerns provided by the workgroup were that the audit alerting criterion is beyond what is required by HIPAA or ARRA. The workgroup recommended the deletion of audit alerting because of the difficulty of implementation and to add “accessed” to the list of auditable actions included with “created, modified, deleted or printed.” Additionally, the auditing of “printing” is difficult for small systems, Baker noted, and “printed” was recommended to be changed to “exported.”

The workgroup was also concerned that that encryption criterion for “user-defined preferences” could be interpreted as person-level proclivities instead of enterprise and security policies, according to Baker, who recommended that the IFR should be clarified so that criterion isn’t personal level proclivity. “The ‘General’ criterion should read ‘[e]ncrypt and decrypt electronic health information according to entity-defined preferences according to the standard,'” stated Baker.

“In general, an entity establishes a security policy which dictates when information should be encrypted and this standard should be revised to reflect this fact,” Baker added.

According to Baker, the IFR specifies that encryption must be symmetric, meaning that both ends use the same encryption key to encrypt and decrypt information. “Public key encryption uses one key to encrypt and another to decrypt and most e-mail programs use asymmetric encryption,” said Baker. “We thought that standards should