Fact or Fiction with EHR Certification Regulatory Interpretations

If enough people believe something, it has to be true, right? In my travels, I’ve found that regulatory interpretations range from being largely factual to wildly fictitious. The latter often results from misinterpretations of regulatory language, improper combinations of regulatory language from different rules, or accurate interpretations getting lost in translation as they are passed from person-to-person. These inaccurate interpretations, intentional or not, often unsurprisingly lead to confusion. Accordingly, I thought it would be helpful to clear up a few things I’ve heard related to certification.  

  • Statement 1: If an eligible professional or eligible hospital combines multiple certified electronic health record (EHR) Modules together (or a certified EHR Module[s] with a certified Complete EHR), that combination also needs to be separately certified in order for it to meet the definition of Certified EHR Technology – *FICTION*
    • Part 2 of the definition of Certified EHR Technology acknowledges that a combination of certified EHR Modules can be used to meet the definition of Certified EHR Technology.  At 75 FR 2023, we clarified that as long as each EHR Module which makes up the combination has been certified, the definition could be met. See also FAQ 17.
    • Combining certified EHR Modules or certified EHR Modules with a certified Complete EHR (or even two certified Complete EHRs) will not invalidate the certification assigned to the EHR technologies. Each EHR technology retains the certification assigned to it.  Our FAQs (such as #7, #14, and #21) identify cases where combining certified Complete EHRs with other certified EHR Modules could occur without any negative effects.
    • Note, generating the “CMS EHR Certification ID” on ONC’s Certified HIT Products List (CHPL) for meaningful use attestation purposes is different. Using the CHPL, an eligible professional (EP) or eligible hospital (EH) generates a CMS EHR Certification ID (a unique alpha-numeric string) to report to CMS as part of its attestation. The CMS EHR Certification ID represents the combination of certified EHR Modules or other combination of certified EHR technologies that meet the definition of Certified EHR Technology and were used during the meaningful use reporting period.
  • Statement 2: The ONC-Authorized Testing and Certification Bodies (ONC-ATCBs) operate under contract with and receive funding from ONC – *FICTION*
    • ONC-ATCBs do not receive funding from ONC to perform their ONC-ATCB duties.  ONC-ATCBs support their operations through testing and certification fees charged to Complete EHR and EHR Module developers.
    • The Temporary Certification Program Final Rule established certain responsibilities and rules for ONC-ATCBs.  ONC-ATCBs must fulfill these requirements and adhere to the rules in order to maintain good standing under the program. For example, ISO/IEC Guide 65 requires ONC-ATCBs to make their services accessible to all applicants (e.g., EHR developers) whose activities fall within its declared field of operation (e.g., the temporary certification program), including not having any undue financial or other conditions.
  • Statement 3: Testing and certification under the Temporary Certification Program does not examine whether two randomly combined EHR Modules will be compatible or work together – *FACT*
    • ONC-ATCBs are not required to examine the compatibility of two or more EHR Modules with each other.  EHR Module developers, however, are free, and highly encouraged, to work together to ensure that EHR Modules are compatible. 
  • Statement 4: The ONC-ATCBs favor big EHR technology developers – *FICTION*
    • The ONC-ATCBs do not favor large developers, and such favoritism is precluded by the international standards to which ONC-ATCBs must adhere.
    • As of June 3, 2011, 438 EHR technology developers were represented on the CHPL.  Of those, approximately 60 percent are small companies (<51 employees) and approximately 12 percent are large companies (>200 employees).
  • Statement 5: Certification doesn’t require that an EHR technology designed by one EHR developer make its data accessible or “portable” to another EHR technology designed by a different developer – *FACT*
    • We are very interested in exploring future certification requirements to improve data portability.
    • If you have any insights on how to improve data portability between EHR technologies, please feel free to leave a comment below. 
  • Statement 6: As an EP or EH, you need to demonstrate meaningful use in the exact way that EHR technology was tested and certified – *FICTION* (mostly)
    • See the jointly posted ONC and CMS FAQs (#24 or 10473
  • Statement 7: Certifications “expire” every two years – *FICTION*
    • A certification represents a “snapshot.”  It indicates that EHR technology has met specific certification criteria at a fixed point in time. In other words, an EHR technology would not “lose its certification” after a given time period.  If, however, certification requirements change (e.g., new and/or revised certification criteria are adopted), the snapshot the certification represents would no longer accurately reflect that the EHR technology meets the changed requirements.
    • In our certification program rules, we indicated that we anticipated adopting new and/or revised certification criteria every two years to coincide with changes to the meaningful use objectives and measures under the Medicare and Medicaid EHR Incentive Programs. We did not, however, set a specific expiration for certifications.  Rather, we explained that once the Secretary adopts new and/or revised certification criteria, EHR technology may need to be tested and certified again. In other words, the previously taken snapshot would no longer accurately represent what is required to meet the adopted certification criteria and, thus, would no longer be sufficient to support an EP or EH’s ability to achieve updated meaningful use requirements.
    • For more information about the validity of a certification, please refer to the Temporary Certification Program final rule (75 FR 36188) and the Permanent Certification Program final rule (76 FR 1301).

As someone who has played a role in drafting all of ONC’s regulations, I take pride in making our rules readily understandable and as easy to read as possible. Sometimes, though, no matter how hard we try to convey a regulation’s intent, there is always another believable interpretation. Hopefully, this blog helps clear up a few points and furthers your personal understanding of our rules.

9 Comments

  1. B L Schnell says:

    Regarding data portability, you shouldn’t be re-inventing the wheel. The Financial Services Industry needed to exchange data reliably and securely for years. Develop an “Interchange” protocol, (for example, FIX) with defined fields, their use, and then each system can develop their own “unload” and “load” methodologies to accomodate it. Not an easy process, but ultimately a necessary one. Do it early in the process, so that companies won’t have the redevelopment effort down the line.

  2. Steve Dubin says:

    Many thanks for the detailed update. Regarding device portability, I would like to share a fascinating, novel, device, called the Amega wand, which helps the body eliminate pain in only 3 minutes. I was a harsh skeptic, now, I am a user.

    Scientific Credentials: It works on the principle; Zero-point Energy (ZPE) developed by iconic scientists, Albert Einstein and Otto Stern in 1913, using a formula called Zero Point Energy (ZPE), developed by Max Planck in 1900, and later endorsed by Nikola Tesla and Thomas Edison. The Amega Wand is the first device to harness ZPE.

    I am happy to share this info at: amega
    wand

  3. Axel Arroyo, MD MPH says:

    Hi everybody

    There is some confusion (at least in my setting, Puerto Rico) about what happened if the currently certified software modify its software version (ie. v 3.0 to 3.1). It is necessary that the software be re-certified? If yes, how this re-certification affect the users with the old version that are under attestation? How the users can control version changes that not affect their investment? I hope has been clear!!

  4. Frank Poggio says:

    Thanks for taking the time to address these complex issues. I have two comments. Before I get into my comments let me say I have worked with (and am currently working with) many best of breed /niche / and smart device suppliers guiding them through the ONCHIT certification process. I have had the opportunity to work with several ATCBs and find them to be very concerned and helpful, yet at same time struggling to answer the many questions that the confusion you note creates.

    My observations and suggestions are:

    You state the ONCHIT program does not favor big technology vendors. I do not believe it was designed nor promulgated with that intent. Yet, I can site many specifics that show in its implementation it does favor big technology at the expense of departmental or niche solutions. For example:

    • The certification criteria for demographics (170.306(b)) requires capturing data elements for date of death and cause of death. If I am a full EHR vendor I would usually have these data elements in my medical records sub-system. If I am a best of breed vendor say selling an appointment system, or an ancillary system such lab or radiology, I would usually have a registration component as part of my system. When registering a patient for care or admission these systems do not ask for date of death, it might be a little disconcerting. Hence, if an EHR Module vendor wants to be certified for 170.306b criteria they must add death questions to their system, inputs that no doubt will never be used. Clearly a waste of time and resources.

    • Another example is Vital Signs (170.302 (f). To be certified on this criteria a provider needs to track blood pressure, BMI and produce growth charts for patients aged 2-20. Not a problem for a full EHR that includes a pediatric module, but a real challenge for a vendor specializing in ICU systems, anesthesia, obstetrics, geriatrics, etc. How do you think it looks to a buyer when they hear from a competing big tech vendor that the competitions ICU system is not certified for vitals signs? Don’t you think the big tech competitor might use this against them in a selling situation?

    And, I have a bucket more examples like this, all I am sure where not intentional but are creating a strong bias against best of breed, niche or smart medical device suppliers.
    I do beg to differ with on the issue about big tech bias. A simple solution to begin to address such issues is to fragment many of these co-joined criteria.

    2) Your explanation is very clear that if a provider runs multiple certified systems all those systems taken together do not have to be certified as one. I personally was never confused about this, but I know others were, Thanks for clarifying it. But here’s examples of where similar issues are still is very confusing.

    If I am running say a dozen niche systems plus a certified EHR and one of those niche systems is non- certified and receives /sends data to the certified EHR is the certified EHR compromised?

    I know that there is an FAQ on the ONCHIT web site that says if my certified system passes data to data warehouse for quality measures then the warehouse needs to be certified as well. But what if my certified system passes data to an interface engine and the engine reformats or combines that data with a data from non-certified system, then passes it to QA warehouse? Do we still have a MU certifiable system? Does the IE need to be certified as well? If you think about the linkage complexities of provider information systems across an institution the amount of data captured, manipulated, and passed on to other systems has an infinite number of permutations. If one or more of those sub- systems is non-certified what are the implications for the overall MU attestation?

    Lastly, an area that is just being touched concerns new releases, enhancements, and bug fixes. I am hearing that after certification if you so much as send out an emergency bug fix and the provider loads the fix, they are now running a non-certified system. Correct? What if the bug fix is part of a critical clinical system and needs immediate attention? Do we wait for recertification, or send it out regardless?

    Thanks in advance for your response to these issues.

    Frank Poggio
    The Kelzon Group
    KelzonGroup.com

  5. Frank,

    In response to your last question regarding bug fixes and affects on certification. The solution may lie in SaaS based solutions, as it will be your vendor’s responsibility to make sure that both maintenance releases and hot fixes are re-certified as necessary. In this sense providers can be confident that they will never have a disruption in certification status as the vendor will take care of these issues.

    These are issues of great importance that require discussion and innovation to understand and overcome.

    Arjen Westerink

    • Frank Poggio says:

      Arjen,
      The issue is the same whether you are running a SaaS solution or a turnkey system. Probably worse if on a SaaS. ON a SaaS dozens of clients will be running a non-certified system if you send out a bug fix before you get the product re-certified. Then ALL clients will be in violation, not just one. Today ATCBs are asking not only for the ID of the release, but also the build number.

      ONCHIT needs to come up with a process to address this when runnig a clinical system or we could adversely impact patient care while we wait for a re-certification.

      Frank Poggio
      The Kelzon Group

  6. Bob Coli, MD says:

    Mr. Posnak,

    It’s well known that huge volumes of data are produced annually by patients undergoing billions of diagnostic tests in hospitals and ambulatory care settings. In addition, studies have shown that 75 percent of the data contained in the medical record consists of diagnostic test results which determine or assist in approximately 70 percent of clinical decision-making. (1)

    This suggests potential value in exploring one future EHR certification requirement that would significantly improve both the usability and the portability of this key clinical data between different EHR platforms and benefit both physicians and their patients.

    This new requirement would create cost and quality incentives for competing ONC certified EHR suppliers to replace the existing user interface, with its infinitely variable formats that display incomplete, fragmented test results data, with a standard cumulative reporting format that can display complete, clinically integrated results on many fewer screens and printed pages and facilitate their efficient viewing and sharing.

    Although truly disruptive technology and business model innovations are challenging to implement, they are vital to ultimately achieving seamless semantic and process interoperability in the American healthcare industry.

    (1) http://www.chcf.org/~/media/Files/PDF/E/PDF%20ElectronicLabResultsExchangePolicy.pdf (page 2) Exit Disclaimer

    Sincerely,
    Bob Coli, MD

  7. [...] Division within the Office of the National Coordinator for Health (ONC), wrote a very helpful blog on fact and fiction related to the ONC certification program. We have recently had many questions [...]

Leave a ReplyComment Policy


*