HIT policy committee wants flexibility in EHR rules

Buyers of so-called “modular” components of an electronic health-record system should be able to tell whether the software they're purchasing will meet minimum privacy and security requirements simply by reading the product label, according to a work group advising HHS on health information technology policy issues.

Federal policymakers want to provide flexibility to accommodate a variety of health IT in their rulemaking for the EHR subsidy program under the American Recovery and Reinvestment Act of 2009, commonly known as the stimulus law.

Instead of buying one comprehensive EHR from a single vendor, policymakers expect hospitals and even some office-based physician practices will buy and use pieces of an EHR from multiple developers, cobbling together enough functionality to meet the meaningful-use requirements of the stimulus law.

The law is offering up to an estimated $27.3 billion in subsidy payments for buyers of EHRs that meet federal standards, including those for privacy and security, and are using their systems in a “meaningful manner.”

But members of a privacy and security work group to the federally chartered Health IT Policy Committee want to ensure those buying and banging into place a complete EHR system from mixed parts don't inadvertently end up with privacy and security holes in their systems.

In a few days, the public comment period closes on an HHS proposed rule creating a permanent procedure for testing and certifying EHR systems as capable of meeting stimulus law standards, including those for privacy and security. To beat that deadline, the work group Thursday brought a few recommendations on composite EHRs to the full HIT Policy Committee for official approval and submission to the Office of the National Coordinator for Health Information Technology at HHS. The HIT Policy Committee was created pursuant to the stimulus law to advise the ONC on health IT matters.

In a letter to the ONC containing their formal recommendations, the privacy and security work group suggested that any components of an EHR system submitted separately for testing and certification be required to carry a label that includes:

• A complete description of the environment within which the module is intended to operate (in other words, the assumptions about how the module will be used, what other interfaces are necessary, whether features are not functional under certain conditions, etc.).
• Which of the privacy and security certification criteria are accomplished by the EHR module and which are not (again, when used as intended).
• If the product is designed to perform a specific privacy and security capability, a specification of the interface through which the security and/or privacy services will be provided to other EHR modules.

In the same letter, the work-group members also said they support an exception to the proposed rule, one that would not require testing and certification of an EHR module if the developer or end-user (in the instance of a home-grown system) “can demonstrate that it would be technically infeasible for the module to be tested and certified to meet some or all of the criteria.”

Still, work-group chairwoman Deven McGraw said members wanted to hear more from ONC about how this exemption would work.

“What we're asking for is ONC to provide some clarification of what they mean by technical infeasibility,” said McGraw, a lawyer and the director of the Health Privacy Project and the Center for Democracy & Technology, a Washington-based think tank.