What changed in the MeaningfulUse Stage2 Standards Regulation?

8/29/2012: I made some minor updates on quality measures, based on recent investigation that resulted in this post.  Changes are marked [8/29 Update]using insertions and deletions.

---

Of course, the biggest issue for everyone whose already done an analysis of the Meaningful Use Standards rule is figuring out what has changed.  I've gone through the rules and outlined for you what's changed since the proposed rule.  I've also added some notes on non-changes for certain items of interest.  Important ones are preceded with a *.

§ 170.102 Definitions

1. Removed Complete EHR Definition and added Complete EHR, 2011 Edition and Complete EHR 2014 Edition.
   Basically, these just define Complete EHR based on 2011 and 2014 Edition Criteria.
2. * Added Common MU Data Set.
   An awesome change, implementing suggestions from this post.
3. Revised definition of Base EHR to include the following [emphasis is mine]:
   (4) Has been certified to the certification criteria at § 170.314(c)(1) and (2):
   (i) For no fewer than 9 clinical quality measures covering at least 3 domains from the set selected by CMS for eligible professionals, including at least 6 clinical quality measures from the recommended core set identified by CMS; or
   (ii) For no fewer than 16 clinical quality measures covering at least 3 domains from the set selected by CMS for eligible hospitals and critical access hospitals.

§ 170.202 Transport standards

No radical changes here.  Direct, XDR and XDM for Direct Messaging, and the basic SOAP Stack used for Exchange specification is still present.  What really changed is not the standards, but how they use them in the certification criteria.  I know a lot of us have indicated that the basic SOAP Stack is XDR/XCA, but it's not really.  It's what Exchange implements these on top of.  However, if you want to believe that it's XDR, or XCA, I'd encourage you to do so.  It won't hurt you, so long as you get the lower security layer right.

§ 170.204 Functional standards

(a) Accessibility. Changed from WCAG Level AA to Level A.

(b) Reference source. Added the InfoButton URL and SOA Implementation guides.  

These would seem to support two different wire formats, but the SOA guide incorporates the URL guide for RESTful messaging.  Both are supported in the IHE Retrieve Clinical Knowledge Profile available now for trial implementation.  The real challenge is that both of these guides are being balloted NOW in HL7, which is a real shame.  I'm hoping we can get ONC to issue an adjustment on this one.

(c) Clinical Quality Measure Changed from NQF QDM to Data Element Catalog.
This is a new one on me, I need to see what this means. [8/29 update] This is basically an extract of data elements from the clinical quality measures, identifying the type of item, and the value set associated with it.  It's based on the QDM, but isn't structured like, nor contain the full QDM content. 

§ 170.205 Content exchange standards

(a)(3) Changed from September 2011 Draft to Consolidated CDA 1.1

(g) Electronic transmission of lab results to public health agencies. Added specifications containing documentation of Errata and Clarifications.

Dropped standards for imaging.  Sorry my DICOM friends.

* Added (h) Clinical quality measure data import, export, and electronic submission.  Using HL7 QRDA Category 1.

* (k) Clinical quality measure aggregate electronic submission.  QRDA Category III.  [8/29 update] This one is rich, because they named the August 2012 draft that hasn't even gone throughfinished a DSTU ballot in HL7 yet.  The content was in draft format for both the Release 1 and Release 2 DSTU (at least as HL7ers understand it).  We reviewed it, but it wasn't part of the "balloted" content, and so hasn't even gone through a minimum level of balloting.  Hopefully, we can use the QRDA Category III work that's being done for Query Health as the "Implementation Guide".

While these are not changes between the proposed and final rules,  you might be interested to know that 

• Yes, they did keep  the CDA document specification for Cancer Registries.  As far as I can tell, the final version is still not CCDA compatible [prefatory text not-withstanding].  Since the certification criteria for this is optional, I can live with that.  They really should have fixed it.
• The LRI work that was pretty close to the edge on deadlines was also retained (using the final version of the guide that went through ballot).
• The HL7 Clinical Genomics Pedigree stayed in, but see changes in the certification criteria later.

§ 170.207 Vocabulary standards

(a)(3) Problems. SNOMED CT July 2012 instead of January 2012.  No big deal.

(e)(2) Immunizations. CVX July 11, 2012.  The 2011 criteria still allows for the July 30, 2009 version.  Again, no big deal.

(f) Race and Ethnicity.  Sorry, still OMB instead of CDC Race and Ethnicity codes.  But since OMB doesn't actually supply codes to store, you can probably use the CDC codes in your EHR, and so you probably should.

(g) Preferred Language.  Change 639-1 to 639-2, allow only terms from 639-2 that have a 639-1 code.  They shifted from 639-1 two-letter codes (that everyone knows), to 639-2 three-letter codes (that are less familiar).  It also isn't clear whether you should use the T (terminology) or B (bibliographic) codes, or whether either is allowed.  Stick with the B codes please if you have to use a language (like French) that has both.  I'm not happy with this change, but it's small enough.

Removed Preliminary Cause of Death. You may still have to report it, but free text is fine.

(h) Smoking Status.  Coded using SNOMED-CT, added Light and Heavy Smoker.  Using US Extensions for Current Some-day Smoker and Light/Heavy smoker.  Make sure you can handle the extra field width.  They came pretty close to what HL7 Recommended (see this post).

(i) Encounter Diagnosis.  No change.  That means it is still ICD-10-CM, but see the certification requirements.

Added (j) Family health history.  HL7 Clinical Genomics Pedigree (again, see certification).

§ 170.210 Privacy and Security

(e) Record actions. You need to record Date and Time (7.2 of the standard) and UserId (7.4 of the selected standard).

(h) Added ASTM E2147-01 (so far, referenced only in 210(e) above)

§ 170.299 Incorporation by reference.

Rewritten and reorganized per Steve Poznack.  These are the references to the standards.

§ 170.314 2014 Edition electronic health record certification criteria.

(a) Clinical.

(3) Demographics. Replace Gender with Sex. To badly sum up a long conversation:  Gender is between your ears, sex is between your legs.

(4) Vital signs, body mass index, and growth charts. Clarified to indicate that this is at a minimum, a patient’s height/length, weight, and blood pressure.  It further says "Height/length, weight, and blood pressure. must be recorded in numerical values only".  What it means is that the numerical value must be in a separate field from the units.  If you don't store units in your product, please let me know who uses it so I can avoid going to them for care if at all possible.

(5) Problems.  No change, still SNOMED CT.

(5) Problems.  (6) Medications.  (7) Medication Allergy List.  Clarified in all three that outpatient settings must manage over multiple encounters, and inpatient settings must manage for an entire hospitalization.

(8) Clinical Decision Support. 

* (i) Evidence-based decision support interventions. Clarified from "in or any combination of the following" to "each one and at least one combination of the following".
This is important.  There's a list of six data elements: (A) Problem list; (B) Medication list; (C) Medication allergy list; (D) Demographics; (E) Laboratory tests and values/results; and (F) Vital signs.  Your CDS interventions must support all six, and at least one combination.  If you had one CDS rule that supports all six data elements, it supports "each one and at least one combination", but it isn't clear whether that would be OK according to this criteria.  That's because there's another criteria using exactly the same wording where it's very clear that you need to support references for EACH one individually.  So, you might need as many as 7 different CDS rules, one for each one, and one for any combination.  That needs clarification.  I've put a question in HHS's inbox on that topic.  It might even be addressed at tomorrows NeHC webinar on Meaningful Use.

(ii) Linked referential clinical decision support.  Added the option to provide reference content (without using any standards) OR using InfoButton.  Basically, it means that you don't HAVE to use InfoButton (but you really SHOULD, there's some great free stuff from MedLine Plus for example and it supports InfoButton)

(iii) Configuration.  (A) Struck out the requirements that CDS be able to be configured based on users clinical setting, or point in the workflow.  Now it is just based on the user's role. (B) (1) based on the six data items previous mentioned above (2) When a patient’s medications, medication allergies, and problems are incorporated from a transition of care/referral summary received [under 314(b)] and
(3) Ambulatory only upon incorporating lab results.
If you can trigger CDS on incorporate  from a transfer of care, just trigger CDS on incorporation [of problems/medications/allergies], regardless of content or context.

(v) Source attributes.
* Added (B) For linked referential clinical decision support in paragraph (a)(8)(ii) of this section and drug-drug, drug-allergy interaction checks in paragraph(a)(2) of this section, the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research/guideline).
For drug interactions, this is probably a serious issue for some.  I don't know how many interaction databases make the citations easily accessible.  Certainly the clinical content (interaction database) suppliers have it, but are you using it?

(9) Electronic notes. Enable a user to electronically record, change, access, and search electronic notes. Unchanged.  Search didn't go away, which is a good thing from my (patient) perspective.

(12) Image results. enable immediate electronic access.  Basically, if there are results or images, the EP needs to be able to get to them from the EHR, but it can launch a separate application which can require another login.  Single-sign-on isn't deployed everywhere. 


(13) Family health history. Enable a user to electronically record, change, and access a patient’s family health history. according to: (i) SNOMED-CT; or (ii) HL7 Clinical Genomics Pedigree.  OK, so this is interesting.  One is a vocabulary standard, the other an exchange standard.  These are NOT equivalent functionally.  The safe bet though, is to record relationships and problems in your database using SNOMED CT.  I'll have to write another blog post on how to exchange them using CCDA, clearly.

(14) Patient lists.list creation.  Clarified to indicate that this is a dynamic capability that can use one or more of problems, medications, demographics, lab test values, and patient communication preferences (ambulatory only).  No canned reporting here.

(15) Patient-specific education resources. Added alternate means to access resources.  This requires use of InfoButton, and allows use of other means.  It isn't clear that you MUST support another mechanism, but I suspect that you do.

(b) Care coordination. 

(1) Transitions of care.
* (i) Receive. No more using /dev/nul for receive.  It needs to support Direct, and can support XDM with Direct, or XDR and the Exchange SOAP Stack.  Please pick one of the latter two. Direct without metadata is just a blob.

(ii) Display. Hooray!  We retain compatibility with existing data formats for display (but only display, you don't have to incorporate those).  I suggested that at the end of this post.  If your EHR is already certified, it already HAS this capability.
(iii) Incorporate. It's just problems, medications and allergies now, and views of each section in the document.

(2) Create and transmit.
(i) Create transition summary.  Uses Common MU Data Set and
(A) Encounter Diagnosis in SNOMED CT OR ICD-10-CM.  Guess which one I'd choose.  If you said ICD-10-CM, you haven't read this post (or a few others).  I'd go with SNOMED CT because you already have to support that for the problem list, and this way, you don't have to jump through ICD-10 hoops (and regs) for this one extra field.  Nice Punt on that one ONC.
(B) Immunizations.  Still there, still have to send them.  Just do it all the time, pretend like it's in the Common MU Data Set and it stops being a problem child.
(C) Cognitive and (D) Functional Status.  These two are brand new.  New in CCDA too, but at least there are sections for it.  
Added (E) Ambulatory setting only. The reason for referral; and referring or transitioning provider’s name and office contact information.
(F) Inpatient setting only. Hospital admission and discharge dates and location; names of providers of care during hospitalizations; discharge instructions; and reason(s) for hospitalization. Discharge instructions.
(ii) Transmit.  Same choices as (1)(i) above for receive.  Basically, use Direct with XDM, or XDR with the Exchange SOAP Stack.

(4) Clinical information reconciliation.  Nothing new here.  Just using this as another opportunity to promote the IHE Reconciliation profile.  We'll be testing it at Connectathon this year.

(6) Inpatient setting only transmission of electronic laboratory tests and values/results to ambulatory providers.  This one didn't go away.  LIS Vendors, listen up!  If you aren't certified, this is an opportunity (at least according to ONC)

* Added (7) Data portability. Enable a user to electronically create a set of export summaries for all patients in EHR technology formatted according to the standard adopted at § 170.205(a)(3) that represents the most current clinical information about each patient and includes, at a minimum, the Common MU Data Set and [see items (A-F) above under Create and Transmit].  Like I said here, the Green Button lives, but under a different name.  This was one of ONC's 13 initiatives in December of 2010.  Well, they decided they could do it via regulation, rather than standards, and they did it.  Its a pretty commonly used solution, so I'm not surprised they stuck with it.

(c) Clinical quality measures.

(1) Capture and Export
(2) Incorporate and Calculate
* Added: (i) Import. EHR technology must be able to electronically import a data file formatted in accordance with the standard specified at § 170.205(h) and use such data to perform the capability specified in paragraph (c)(2)(ii) of this section. EHR technology presented for certification to all three of the certification criteria adopted in paragraphs (c)(1) through (3) of this section is not required to meet paragraph (c)(2)(i) [this paragraph].
(3) Submit.
Added: (i) In accordance with QRDA Category I and III; and See prior comments on Category III
Added: (ii) That can be electronically accepted by CMS.  That's a huge caveat.

(d) Privacy and security.

Ask John Moehrke for his analysis.  I probably did enough damage just interpreting transport.

(e) Patient engagement.

(1) View, download, and transmit to 3rd party.
(i) EHR technology must provide patients (and their authorized representatives) with an online means to view, download, and transmit to a 3rd party ...
(A) View. Using WCAG Level A. Replace the data element list with Common MU Data Elements and (Ambulatory only) The providers name and contact information, (Inpatient only) Added discharge instructions in to dates and reasons for hospitalization.  It's pretty clear from the preface that a CDA Stylesheet on CCDA will enable you to meet the requirements.  The Lantana Group has a free one on this page.

(B) Download.  An ambulatory or inpatient summary and (inpatient only) transition summary in human readable format or according to the CCDA standard.  This is where I had a problem last night with the word OR.  However, it's clear from the preface that the interpretation from the application perspective should be AND.  It's the patient that has the choice, not the application, and the preface clarifies that.  This is one that I hope they either tweak before FR publication, or put out a FAQ on.

* (C) Transmit to third party. Transmit the same data that the patient can download using either Direct, Direct+XDM, or XDR+Exchange SOAP Stack.  If you use XDR, you need to specify the recipient metadata (XDSSubmissionSet.intendedRecipient) in order for the XDM/XDR Gateway capability of Direct to work. Like I said before, pick the XDM or XDR choice here, else you are just giving the receiver a blob w/o any metadata.

* (ii) Activity history log. No substantive changes, but note that audit events for the patient portal on view, download and transmit must be patient accessible.

(2) Clinical summary (ambulatory only)
(i) Create a clinical summary (in CCDA format). No big change here
Added (ii) Customization.  Enable a user to customize the data included in the clinical summary.
Added (iii) Minimum data from which to select. EHR technology must permit a user to select, at a minimum [the Common MU Data Set], and provider’s name and office contact information; date and location of visit; reason for visit; immunizations and/or medications administered during

(3) Secure messaging (ambulatory only).  Added the patient's authorized representative.

(f) Public Health

(1-4) No major changes.  Report Immunizations, lab reports, and surveillance data to public health using HL7 2.5.1.   For reporting syndromic surveillance, ambulatory systems don't have to use the PHIN Surveillance message.  Smart ones will.
(5) Cancer case information.  Made this an optional reporting criterion (ambulatory setting).

(g) Utilization

* (1) Automated numerator recording. Replaced "automated numerator recording" with
EHR technology must be able to create a report or file that enables a user to review the patients or actions that would make the patient or action eligible to be included in the measure’s numerator. The information in the report or file created must be of sufficient detail such that it enables a user to match those patients or actions to meet the measure's denominator limitations when necessary to generate an accurate percentage.
This one is interesting.  You no longer compute the measure.  Rather, you list the patients and actions which which would be in numerator should they be in the denominator, and indicate the minimum (additional) denominator criteria that must be met.  Read page 84 for details on this one.  Let me give a simple made-up example.  Numerator: An advance directive is recorded.  Denominator: Patient is older than 65.  Assume that advance directives can be recorded in a separate (Modularly certified) system.  It doesn't know patient age, only patient id.  It must report all patients for whom there is an advance directive recorded, and indicate that the minimum denominator criteria is AGE > 65.

(2) Automated measure calculation. No change.

Removed (3) Non-percentage-based measure use report.

(3) Safety Enhanced Design. No changes in functionality, just references to different spots in the regulation to adjust for edits.
  

(4) Quality management system. Report on each QMS used for each capability in (3) above, and if none, report on that (to the certifier).  My  expectation is that this is a "Test result", and as such will become publicly available information (see below).

§ 170.523 Principles of proper conduct for ONC-ACBs.

(f)

(8) A hyperlink to the test results used to certify the Complete EHRs and/or EHR Modules

that can be accessed by the public.  No change here.  Test results will become public information.
Added (k)(iii) ... Any additional types of costs that an EP, EH, or CAH would pay to implement the Complete EHR’s or EHR Module’s capabilities in order to attempt to meet meaningful use objectives and measures. EHR technology self-developers are excluded from this requirement.  Again, also to become public information.

---

There you have it.  A seven page summary of changes.  Now to summarize the summary, and then off to the incentives text.  Oh joy!

-- Keith

P.S.  In case you want to know how I got these deltas here are the secrets.

Prerequisites:  Full version of Acrobat which allows saving a PDF to Word Format  (version 7 or later), and a copy of Word (2007 or later).

1. Save the PDF of both rules (proposed and final) as a Word document
2. Stripped out the prefatory material by editing the documents in Word.
3. Used Word's Compare two Documents feature, and disabling the stuff you don't care about, like white space and formatting.

The end result is a document that has change tracking marks which shows the deltas.