Saturday, February 22, 2014

The Voluntary 2015 Edition Electronic Health Record Certification Criteria

There's nothing like a crisp New England winter evening, a roaring fire, a cup of cider, and a 242 page Notice of Proposed Rulemaking to fill your Friday night.

I've summarized the preamble and all 50 criteria to save you time as you consider the proposals during the 60 day comment period.    Note that no vendor needs to implement 2015 criteria and no provider needs to adopt 2015 certified software, hence the term voluntary.  In many ways, this document is meant to signal what might be included in the 2017 edition that supports Meaningful Use Stage 3.

Roughly 60% of the 2014 Edition EHR certification criteria are unchanged in the 2015 Edition. The remaining certification criteria proposals for the 2015 Edition fall into four general categories: clarifications, standards updates, revised approaches, and new certification criteria proposals.

As with the Meaningful Use Stage 3 proposals, I'll pose questions, not to be judgmental but to get us all thinking about the scope, timing, and purpose of the certification program over the next several years.

The preamble highlights several big ideas -  elimination of the 'complete EHR' designation, separation of content/transport certification criteria, adoption of new standards, more frequent certification rule making, and the need for 2017 edition proposal feedback.

Complete EHR was a very confusing concept to me that led many to buy single vendor systems as the "safest" option instead of assembling modules.   I applaud the idea of eliminating terms like Complete EHR and Optional Certification criteria.   Each certification criterion should stand alone and during attestation you should "fill your shopping cart" with only the certified modules you need.

Separating the content and transport certification criteria is a good thing.  The 2014 Edition which linked the two concepts proved to be very problematic in Massachusetts where the state HIE performs all of the Direct and XDR functions we need, so no EHR requires transport capabilities.   Yet because EHRs had to be certified to do both content and transport interoperability, extra work and expense was incurred.

The logic behind more frequent certification rules is that it enables "bug fixes" and more rapid adoption of standards.    However, we should ask the question - even with a voluntary program, just how fast can we develop software, install upgrades, revise workflow, educate clinicians, and support new software versions?   My experience is that changes of this nature take 3 years from regulation to attestation, at a minimum.

Here's my advice while reading the 50 certification criteria:

Focus on the fixes.  There were many challenging issues in the 2014 Edition.  The 2015 Edition fixes several of them.  Even if something looks more complex (like separating content and transport criteria),  it is simpler, and provides more market flexibility.

Identify the burden reduction.  Vendors of "non-MU Eligible"  software such as long term post acute care no longer need to develop "MU-required" functionality such as measure calculation to get certified.

Recognize that about 30% of the document is requesting comments for the 2017 Edition, not specifying 2015 requirements.

The proposals are just that - proposals.  It's hard to know how many will be incorporated into the final rule.  Much depends on feedback from stakeholders.   Certainly the Standards Committee and its Implementation Workgroup will offer substantial feedback.

Although some of the proposals do not seem like the highest priorities, there is someone inside or outside government who believes each proposal is important to healthcare.

If you have questions about intent, re-read the pre-amble.   It's well written and provides a context for the 50 proposals.

Here are the actual certification criteria

1.  Computerized Provider Order Entry
The functional requirement for medication/lab/rad ordering is split into 3 modular criteria, enabling novel functionality like mobile medication ordering to reside in its own application.   Since lab ordering standards are not consistently implemented, this proposal suggests using the S&I framework Laboratory Orders Initiative Draft Standards for Trial Use which have been approved by HL7 ballot.

2.  Drug-drug, drug-allergy interaction checks
The proposal includes a provision to consider tracking user actions i.e. what advice was ignored and what were the consequences when advice was ignored?    The interesting debate here is what to track and what to do with the tracking data.   This could be burdensome and have limited customer demand.

3.  Demographics
The proposal includes a new standard for recording preferred language that focuses more on spoken rather than written language.   It also requires that EHR technology must enable a user to electronically record, change, and access the date of death and the preliminary cause of death.

4.  Vital signs, body mass index, and growth charts
No change, although there is a discussion of requiring controlled vocabularies such as UCUM for units of measure in the EHR and in transmission of summary records.

5.  Problem list
No change

6.  Medication list
No change

7.  Medication allergy list
No change

8. Clinical decision support
The proposal adds a requirement to demonstrate decision support based on specific demographic requirements such as gender or date of birth.   It also simplifies the Infobutton demonstration criteria to better align with the capabilities of the standard.  Finally, the proposal would require importing of externally authored decision support rules and a query/response interface to remote knowledge resources.   We should debate the complexity, standards maturity, and appropriate initial use cases to demonstrate this functionality.

9. Electronic notes
The proposal requires search for information across separate notes within the EHR i.e. a Google-like function for structured and unstructured data.   It could be very complex.

10. Drug formulary checks
No change

11. Smoking status
No change

12.  Image results
No change

13. Family health history
The proposal requires the use of the HL7 Pedigree standard, eliminating the option to use SNOMED-CT for family history.

14.  Patient list creation
As with decision support, patient list functionality  must be able to filter based-on specific demographic requirements such as gender or date of birth.

15.  Patient-specific education resources
As with decision support, Infobutton requirements have been simplified.   There is an odd provision in this section requiring the use of Infobutton and an alternative to Infobutton.  That should be debated.

16.  Inpatient setting only – electronic medication administration record
No change

17.  Inpatient setting only – advance directives
No change

18.  Implantable Device List
This proposal requires the EHR to record and display a unique device identifier (UDI) to facilitate the widespread capture and use of UDI data to prevent device-related medical errors, improve the ability of hospitals and clinicians to respond to device recalls and device-related patient safety information.  UDI must also be incorporated into the CCDA interoperable data sets for

170.315(b)(1) – Transitions of care.
170.315(b)(6) – Data portability.
170.315(e)(1) – View, download, and transmit to third party.
170.315(e)(2) – Clinical summary.

The FDA work on UDI is excellent.  We should debate the role of the EHR for recording UDI data versus other alternatives such as registries.

19.  Transitions of care
As described in the preamble, content and transport are split into two certification criteria.  The best part of this revision is that it aligns certification with the notion that EHRs may communicate with regional or third party HISPs without the need for every EHR to be its own HISP.

Updated standards are used for transition of care content.

Rather than require healthcare information exchange with a different vendor's EHR (very hard to measure), the certification criteria will be the EHR's capability to import hundreds of different CCDAs with at least 95% success.   That could be very burdensome.

The proposal also includes a requirement that the EHR support appropriate demographic fields for patient matching - name, gender, date of birth, address etc.

20. Clinical information reconciliation and incorporation
The term "incorporation" can be confusing so this proposal formally defines CCDA import as reconciliation of externally provided summaries including reconciliation of medications, medication allergies, and problems.

21.  Electronic prescribing
No change

22.  Incorporate laboratory tests and values/results
The proposal includes updated standards - HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Laboratory Results Interface, Release 1 (US Realm) (S&I Framework LRI) with Errata

23.  Inpatient setting only – transmission of electronic laboratory tests and values/results to ambulatory providers
The proposal includes the same updated HL7 Version 2.51 LRI standard.

24. Data portability
The proposal includes an updated standard - Consolidated CDA Draft Standard for Trial Use, Release 2.0 plus a requirement that the Universal Device Identifier data be exportable.

25.  Clinical quality measures – capture and export
No change

26.  Clinical quality measures – import and calculate
No change

27. Clinical quality measures (CQM) – patient population filtering
This proposal requires filtering of CQMs by patient population characteristics such as
Practice site and address, Tax Identification Number (TIN), National Provider Identifier (NPI),Diagnosis (e.g., by SNOMED CT code), Primary and secondary health insurance, including identification of Medicare and Medicaid dual eligibles, Demographics including age, sex, preferred language, education level, and socioeconomic status.   We need to take a careful look at the burden of all the various quality related measurement provisions of Meaningful Use, as they are already overwhelming.

28.  Authentication, access control, and authorization
No change, but there is a discussion of the future need for two factor authentication in support of controlled substance e-prescribing and possibly remote access.

29.  Auditable events and tamper-resistance
The proposal suggests that disabling audit logs should be prohibited.  I'm not aware of any EHR which enables audit logs to be disabled.

30.  Audit report
No change

31.  Electronic Health Record Protections
§ 170.315(d)(4) (Amendments)
§ 170.315(d)(5) (Automatic Log-Off)
§ 170.315(d)(6) (Emergency access)
§ 170.315(d)(7) (End-User Device Encryption)
§ 170.315(d)(8) (Integrity)
No change

32.  Accounting of Disclosures
No change

33. View, Download, and Transmit to Third Party
A patient must be able to download an ambulatory or inpatient summary in only the human readable format if they just want that, in only the Consolidated CDA format if they just want that, or in both formats if they want both.

As with other interoperability criteria, this proposal decouples transport and content certification.    I've mentioned in previous blogs that this is important, since the ecosystem of infrastructure and applications to support patient transmit is still evolving.

This proposal focuses on a patient’s ability to choose the destination to whom they want to send their health information and the outcome, rather than the specific mechanism of transport.

The proposal includes more rigorous accessibility guidelines - WCAG 2.0 Level AA

34.  Ambulatory setting only – clinical summary
The proposal includes CVX codes for immunizations, and requires the updated Consolidated CDA version (Draft Standard for Trial Use, Release 2.0)

35.  Ambulatory setting only – secure messaging
No change

36.  Immunization information
No change

37.  Transmission to immunization registries
Updated standards

38.  Transmission to public health agencies – syndromic surveillance
The proposal expands possible standards to include HL7 CDA and QRDA III for ambulatory users only

40.  Inpatient setting only – Transmission of reportable laboratory tests and values/results
The proposal includes updated HL7 2.51 standards

41. Ambulatory setting only – cancer case information
The proposal decouples content and transport for delivery of cancer case information to registries.

42.  Ambulatory setting only – transmission to cancer registries
The proposal includes updated standards

43. Automated numerator recording
No change

44. Automated measure calculation
No change

45.  Safety-Enhanced Design/Quality Management System
No change

46. Non-percentage-based measures report
Since some of the certification criteria are not percentages, this proposal requires that an EHR be capable of electronically generating a report that shows a user has interacted with the technology capability associated with a non-percentage-based MU measure during an EHR reporting period.    This could be very burdensome and needs to be reviewed.

47. Transmit – Applicability Statement for Secure Health Transport
This proposal certifies only the Direct protocol

48.  Transmit – Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging
This proposal certifies Direct and XDR/XDM

49.   Transmit – SOAP Transport and Security Specification and XDR/XDM for Direct
This proposal certifies SOAP and XDR/XDM

50.  Transmit – Applicability Statement for Secure Health Transport and Delivery Notification in Direct
This proposal certifies Direct and end to end result delivery notification

These last 4 criteria may seem confusing, but their intent is to enable EHR vendors to certify as much or as little transport functionality as they want so that an EHR can be a modular component in an HIE/HISP ecosystem.

My takeaways from the 242 pages

1.  60% of the criteria are the same. 40% are modified/new.   Many of the modifications are to correct issues in the 2014 Edition and are reasonable.  Some of the new criteria could be very burdensome.   We need to debate the collective burden of the Meaningful Use program in the context of ICD10, ACA and the HIPAA Omnibus rule burdens.    Each individual project may be reasonable but the collection of all the projects is not.

2.  ONC is proposing more frequent certification NPRMs.   We should debate if increased  frequency is a good or bad thing given the realities of implementation and competing projects.

3.  Overall we should debate the role of certification going forward.  Should government provide a list of EHR functional priorities or should that be left to providers, patients, and developers?   How prescriptive should government be i.e. roads should be 30 feet wide, but drive whatever you want versus your car must have 2 headlights, a catalytic converter, seat belts, and 4 tires versus you must drive a SUV.

4.  Major new concepts in the document to review include
HQMF quality measure definition as a 2017 criteria (import quality measures automatically)
HealtheDecisions for decision support rule importing/knowledge access in 2015
Recording Universal Device Identifier for implants
QRDA II (a new format for quality reporting) as a 2017 criteria
Stratified quality reporting in 2015
Testing CCDA receiving ability with hundreds of  CCDAs in certification,  importing 95% successfully
Searching across the entire patient record
Tracking non-percentage based MU measures in a report
Upgrading lab interface standards including orders
Two factor authentication for e-Prescribing and remote access

5.  Although the fixes are much appreciated, are they too late since most vendors in the Meaningful Use program have already completed the work of certification with the 2014 Edition, despite its flaws?

As with the Meaningful Use Stage 3 proposals, let the debate begin!

1 comment:

  1. Very well done! I wrote a blog post a few months back and it said "Government and consumers are learning a real, cold hard lesson today about the complexities of IT systems today" and let's say I think some of it is sinking in, slowly and God knows the roll out of Healthcare.Gov should have opened some eyes, how many though we don't know:)

    "Auditable events and tamper-resistance
    The proposal suggests that disabling audit logs should be prohibited. I'm not aware of any EHR which enables audit logs to be disabled."

    I read this and I have seen the news articles about it and have just passed them off but what software company in their right mind would even think of this as an option, that is unless they want to get sued:) As a developer nobody is going to allow that.geez..it just floored me to see that and in my humble opinion the ONC needs the view of a few more coders once in a while. Maybe I'm nut but I wrote a while back that the ONC could easily be moved to the FDA so they would have better access to the FDA software engineers and vice versa input on the mHealth issues as they could reside at the FDA as their own entity too and collaboration would flourish that way, but what do I know other than the fact that a couple at the ONC on Twitter said they liked the idea (grin).

    In short we have a huge "perception" problem out there in the way that some of this stuff makes it to the news and again I we might want to vary a little bit from the old story telling news formats and get down to brass tactics on some of this. Lawmakers spend hours and days and weeks on legal verbiage while computer code on servers runs hog wild as those who are smart with their models just code around it and we have what is known as the "loophole"..

    You can have more patience than I can ever imagine at times..and a visit to the llamas on the farm is a welcome experience as nice break from pressures of Health IT...as we all need to mentally recoup at times for sure. Again, nice write up and direction.

    ReplyDelete