Help Shape the EHR Certification Process for Privacy & Security
ONC’s Certification Program includes the certification of two types of 
electronic health record (EHR) technology: Complete EHR and EHR Module. To meet the EHR adoption requirement to qualify for meaningful use incentive payments, an eligible professional or hospital can use either a Complete EHR, or a set of EHR Modules that collectively meets the definition of Certified EHR Technology (CEHRT). Responsibility for assuring that a set of certified EHR Modules can be successfully and securely integrated together is left up to the adopter.
Certified EHR Modules
Certified EHR Modules offer adopters the flexibility to select “best of breed” products. At the same time, a decision to meet the CEHRT definition by combining a set of certified EHR Modules could affect system-wide security and the consistency through which an enterprise security policy is enforced if implementers are not careful and do not fully understand the technical differences among the certified EHR Modules.
Combining a set of certified EHR Modules may introduce several types of security risks:
- A single EHR Module on its own may not provide the security functionality an enterprise needs to comply with HIPAA;
- The combination of certified EHR Modules may provide redundant security functionality that cannot be integrated with, and may even conflict with, enterprise security solutions within which all of the certified EHR Modules would operate; and
- The collective, system-wide behavior of separately developed certified EHR Modules operating together may result in system behaviors that put enterprise security at risk.
2011 Edition EHR Certification Process
The 2011 Edition EHR certification process requires that EHR Modules meet all security certification criteria unless the presenter can demonstrate that certain security capabilities are either technically infeasible or inapplicable. In too many cases, this approach has led to product developers’ implementing security functions that will never be used in actual operations, or having to generate documentation explaining why the requirements were inapplicable or technically infeasible, but providing no real value beyond the EHR certification process. Also, this approach discourages developers and implementers from taking advantage of external security services, such as those provided by enterprise security solutions (for which certification is generally not required).
2014 Edition EHR Certification Process
In response to these concerns, the 2014 Edition Standards and Certification Criteria final rule eliminated the upfront requirement for EHR Modules to be certified against the privacy and security criteria. Rather, privacy and security criteria were made part of the “Base EHR definition” that all CEHRT must meet. In other words, if an eligible professional or hospital elects to use a set of certified EHR Modules as its CEHRT, one or more modules in the set must meet the security criteria, and it is left up to the eligible professional or hospital to make sure the modules can interoperate securely and/or work within their overall organizational/enterprise approach to security. So an EHR Module may or may not implement privacy and security capabilities in order to be issued a certification, and from a different perspective an EHR Module that meets the Base EHR definition may or may not make its security services available to other modules (because such “openness” is not currently required as part of certification).
This potential leaves open the possibility that a certified EHR Module could interact in unexpected ways with the protection provided by another EHR technology certified to provide privacy and security services – or that privacy and security services assumed to be available from EHR technology certified to meet the Base EHR definition may not be accessible to other modules.
ONC’s Approach to the Next Edition of EHR Certification
To help figure out the path forward, ONC tasked the Privacy and Security Workgroup of the HIT Standards Committee (HITSC) with addressing the following questions, and providing recommendations, targeted for the 2016 Edition of EHR certification.
- Should ONC’s approach stay the same for the next Edition of EHR certification?
- Are there small changes that could be made that could also have a big impact?
- For the 2016 Edition, might it be possible to require that each EHR Module be certified against some minimal set of privacy and security criteria, without imposing unreasonable regulatory burden?
HITSC’s Preliminary Recommendation
At the November HITSC meeting, the Workgroup presented its preliminary recommendation [PDF - 711 KB]: that each EHR Module presented for certification be required to meet each of the security criteria, except Amendments and the optional criterion for Accounting of Disclosures, using one of four paths:
1) Implement the functionality;
2) Implement a standards-based interface to external security services to meet the functionality;
3) Implement a non-standards-based service interface to other certified EHR technology;
4) Document why the criterion is inapplicable or technically infeasible.
The HITSC discussed the four paths and suggested that the distinction between “standards-based” and “non-standards-based” be dropped, and replaced with a requirement for system documentation describing the interface in sufficient detail to enable integration. The HITSC also recommended the paths be applied to all privacy and security criteria (no exceptions), since any non-applicable criteria could be addressed using path #4.
Provide Feedback on the HITSC Recommendation
We are soliciting your feedback on the following recommendation. For 2016 Edition EHR certification, each EHR Module presented for certification should be required to meet each privacy and security criterion using one of the following three paths:
- Demonstrate, through system documentation and certification testing, that the EHR Module includes functionality that fully conforms to the privacy and security certification criterion.
- Demonstrate, through system documentation sufficiently detailed to enable integration, that the EHR Module has implemented service interfaces that enable it to access external services necessary to conform to the privacy and security certification criterion.
- Demonstrate through documentation that the privacy and security certification criterion is inapplicable or would be technically infeasible for the EHR Module to meet.
Please provide your comments using the Comment function below. Thank you.
I would like to see the certification of EHRs mean that the EHR product can meet the Meaningful Use standard. The vendor is charging thousands of dollars to providers just to meet Stage I MU and the product is already certified. When are we going to be protected from vendors that are charging for all the money we get as an incentive payment just so we can meet the Stage of MU we are in. I am dreading what the charges will be for each additional stage. The program monies are not going to the Health care community they are going to the software vendors.
We suggest you work with the local Regional Extension Center (REC), which can help you review contracts before signing to ensure that you have selected a product that meets your needs and allows you to meet your bottom line. You can find a list of RECs at http://www.healthit.gov/providers-professionals/regional-extension-centers-recs
The solution is to have defined Modules, not a free-for-all. With defined Modules one can define the Interface between the modules. Thus defined ‘standardized interfaces’, that is interoperability. With the defined modules and the interfaces between the modules; then one can identify the appropriate place for security functionality and what security is needed on the interfaces. It is through this defined modules with standardized interfaces that is a precondition for having standardized security and privacy functionality including enforcement that span beyond the core certified EHR definition.
This is easy to do with some modules, not so easy with others. But by starting with some easy modules, such as departmental EHRs, we can narrow the gap. There are well defined standards interfaces, interoperability, between the main EHR and the departmental EHR.
* ADT — IHE-PIX, PDQ, and PAM
* Orders/Results — IHE Radiology Scheduled Workflow, Labratory Workflow, etc
* care coordination documentation — HL7 v2 MDM, CDA, CCDA, IHE
And all of these are being transformed into RESTful services with HL7 FHIR; and available for cross-organization exchange through IHE XDS/XCA/XDR/XDM.
Once these interfaces are defined, one looks at the interface requirements. Sometimes the security need only be machine-to-machine (IHE-ATNA). But sometimes user identity is important (IHE-EUA, IHE-XUA, or IHE-IUA). A big advantage of having these modules well defined and interfaces well defined are that one can also look at deeper requirements like Security Audit, Privacy Enforcement, Ammendments, and accessibility.
Thank you for the opportunity to respond.
I am a consultant in the HIT/EMR industry and have worked with dozens of EHR Module vendors in assisting them through the ONC Certification test process. I have experience with almost all the ACBs and am very familiar with the P&S requirements. Your flexibility in considering three avenues for EHR Modules to address the criteria is appreciated, however I have a very serious concern about Path 2.
Path 1 is basically the Stage 1 requirement, although it has been a small hurdle for some vendors I have worked with, for the most part it has been doable. Path 3 also exists under Stage 1, but what I have found in working through dozens ACB tests is that the rules for exception are not well defined and can vary significantly from ACB to ACB. I have seen several cases where exceptions were granted, then using the same logic with another ACB the request was quickly denied.
My real concern is with Path 2, integration of EHR Module privacy and security functions through an enterprise vendor. At a high level this suggestion sounds reasonable, and tools and specific data instances can be cited as to its feasibility. (See previous writer’s comments). But as anyone who has ever developed and installed a specialty application for health care can tell you there are real devils in the details. Furthermore, implementing the recommendation so as to facilitate linkages to and from an enterprise system would require both parties (enterprise vendor and module vendor) to closely co-exist within a P&S environment.
I believe if HITSC is going to seriously consider that EHR Modules meet the criteria via Path 2 then HITSC must also mandate that enterprise systems allow robust two way linkages to their products. In addition ONC must direct enterprise systems to not delay or hamper in any way the implementation or operation of such links. I personally have seen too many real life situations where getting an enterprise vendor to cooperate in a timely manner was next to impossible, and these were for what I believe were ‘simple data’ interfaces. In fact some enterprise vendors use the delay tactic as part of there selling strategy.
In summary, unless Path 2 is greatly expanded to incorporate specific technical, functional and more importantly timing requirements for both full and module EHR vendors it will create significant client issues that could lead to the demise of many EHR Module vendors.
Frank Poggio
The Kelzon Group
KelzonGroup.com
flp@kelzongroup.com
Path 1 is preferrable: 1.Demonstrate, through system documentation and certification testing, that the EHR Module includes functionality that fully conforms to the privacy and security certification criterion. This is the best way to ensure P&S compliance is equally applied to al vendor solutions.
Sounds very much like a catch 22, and does leave the board with a difficult decision. I am tending to lean on the side of John M’s point of view. I think sturcture is needed and that can only be achieved properly through set modules and not the ‘free-for-all’ method. I think it is possible for the EhR modules to meet criteria 2 if implemented properly.
So I provide security services to an EHR module that runs in a Common Criteria EAL 4 OS configuration where the STA does S/MIME to the Direct address endpoint described in the distributed Provider Directory which is based on X.500/LDAP which is common to enterprise environments, and scalable to the Internet.
Since the components are all COTS and standards based it is completely documented. Looking at the slide for the EHR modules, it does not appear to require certification since it is closest to the Simple SMTP risk model between EHRs doing Direct without a HISP. What does make it different is that the message can not be modified after hitting an external SMTP MTA for transport. Interoperability takes place between the module and the EHR, not in the middle, so it does not require a HIE.
Things like ATNA are simply built in to the OS.
Imagine how much smarter you could make the EHR if the EHR could tap into the various silos of healthcare data in order to create focused patient analytics. Unfortunately, we can’t even design these type of smart EHR software, because too much of the data is unavailable to EHR software. I love to think about the innovation that would be possible if there was a free flow of data to those that needed it in healthcare.
Certainly there are plenty of security risks and privacy concerns to consider. However, we can’t let that challenge be an excuse for us not to create focused patient analytics that will benefit patients.
I hope that my comments are not out of line. I’m sure that some will feel that I am taking a tangent here, but I feel that my concern is something that should be taken into account when considering Electronic Health Information.
I have seen some many articles, comments and advise about Electronic Health Records that deal with the Providers or Hospitals. But hopefully we all realize that the Electronic Health Record is about a Patient, a person, someone who we keep saying needs to be more involved with their own personal healthcare. Yet, no one is exploring how better to get them involved when just looking at EHR systems. EHR systems are traditional specific to Healthcare Providers and Hospitals, not patients.
Therefore, we need to also consider Personal Health Record (PHR) systems. One of the meaningful use Stage 2 criteria was for Providers to “Provide patients the ability to view online, download and transmit their health information within four business days of the information being available to the EP.” The ruling goes on to say that the “Measure” should be 50%. What better way for Providers to fulfill this requirement than through passing that information on to a PHR system. This eliminates the need for the provider to purchase and/or implement an online interface for their patients. A PHR system is much better for the Patient because PHR systems will centralize their medical history. If a patient has multiple providers, which is one of the main reasons for having these rulings, and each Provider has their own EHR interface, then the patient will find themselves having to log into 2 or more systems to see their medical records. Furthermore, PHR systems allow the patient to control their data by allowing them to determine who may have access to their data. Most PHR systems also allow patients to enter and track other valuable information about their health such as their diet, their exercise program, daily vital signs and so much more. PHR systems should be included in the certification process, although with different functionality requirements, but not different security requirements. There should also be funding set aside for developing the PHR systems to ensure that patients have the best opportunity to manage their overall healthcare.