Ensuring EHR Module Security, PrivacyFederal Panel Seeks Comments on Proposals
To qualify for the HITECH Act electronic health record incentive program, hospitals and physicians can either implement a comprehensive EHR system or a group of EHR modules. Federal regulators are pondering how best to ensure security is adequately addressed if the modular approach is taken.
Sweeping privacy and security requirements for electronic health record modules were left out of the software certification final rule for Stage 2 of the program, which starts in 2014. Now a federal advisory panel is seeking public comment on whether privacy and security requirements for individual modules should be included for Stage 3, slated to begin in 2016.
Hospitals and physicians must use EHR software that's been certified as meeting HITECH requirements to qualify for financial incentives from Medicare or Medicaid.
The Health IT Standards Committee's privacy and security workgroup is seeking comments about its preliminary recommendations that aim to bolster minimum requirements for EHR module privacy and security in Stage 3.
Feedback is being gathered via the comments section of a blog by workgroup chair Dixie Baker on the Office of National Coordinator for Health IT website. The workgroup will accept comments this month and consider the feedback as it prepares its formal recommendations, which should be completed by early January, Baker says.
To meet the EHR adoption requirement to qualify for incentive payments, healthcare providers can adopt either a complete EHR or a set of EHR modules that collectively meet the definition of certified EHR technology, Baker explains.
Under the Stage 2 software certification rule, however, the responsibility for assuring that a set of certified EHR modules - which might come from a variety of vendors - can be securely integrated is left to the physicians and hospitals who adopt them, Baker says. Examples of modules include e-prescribing, clinical decision support and lab management.
The Stage 2 rule eliminated the upfront requirement for individual EHR modules to be certified as meeting the privacy and security criteria that had been included in the Stage 1 rule. Those requirements were dropped because some software vendors contended that they were unnecessary and burdensome, Baker says.
For instance, a Stage 1 requirement for automatic log-off capabilities might not have been a good fit for a clinical decision support module because users typically would access it by logging into other components of an EHR, Baker says.
The Stage 2 rule introduced the concept of a "base EHR definition" - a set of core attributes, including privacy and security, that healthcare providers must adopt through using a "complete EHR" or through a combination of EHR modules. If healthcare providers take the modular EHR approach, they may mix and match products that, when combined, fulfill the "base" security and privacy attributes.
But taking that piecemeal approach can be a daunting task for healthcare providers, especially smaller physician offices that don't have deep technology skills or resources, says Baker, who is a partner at consulting firm Martin, Blanck and Associates.
The problem is complex because some modules might meet certain privacy and security capabilities on their own, but they might not have an interface to allow those same security and privacy services to be tapped by other EHR modules that lack those features.
Or, in other cases, some EHR modules may have privacy and security capabilities that interfere or conflict with the capabilities of other modules.
"It's up to the healthcare providers to figure this out, or they can depend on vendors or integrators to help sort it out," Baker says. But if issues are not sorted out properly, security could be undermined, she contends.
To address these concerns, the workgroup is considering adding back core security and privacy criteria for each individual module in the Stage 3 rule, Baker says.
The advisory panel has drafted a recommendation that all certified EHR modules must meet a minimum set of requirements, including:
- Authentication, access control and authorization;
- Auditable events and tamper control;
- Automatic log-off;
- Emergency access;
- Encryption of data at rest;
- Data integrity safeguards.
Vendors of EHR modules would have three paths to choose in meeting those certification criteria:
- Implementing the functionality in a module;
- Implementing interfaces to provide access to the core security and privacy capabilities;
- Documenting why the criterion is inapplicable or technically infeasible.
In addition to the work of Baker's workgroup, the Health IT Policy Committee recently issued a request for comment on formal recommendations regarding privacy and security requirements for the Stage 3 meaningful use rule (see: Feedback on HITECH Stage 3 Rule Sought).