Everything HITECH

Observation Services Method Nuances

In September of 2010, CMS issued FAQ 10126 giving providers options on counting patients in numerator and denominator of Meaningful Use Measures.  However, guidance on criteria and processes by which EHR software would be certified were issued in the Federal Register prior to this guidance (January of 2010), and have not been re-issued since. 

So … does your standard EHR automatically know what decision you have made?    

---

Action Item:  Verify that the list of 12 Meaningful Use Reports providing the option for “all ED Patients” or “Observation Services Patients”, and test numerator / denominator for completeness and accuracy.

CMS has stated their desire to include in the denominator visits to the emergency department (ED) of sufficient duration and complexity, that all of the Meaningful Use objectives for which the ED is included would be relevant.   Giving hospitals the option to select between “All ED Patients” and “Observation Services Patients” seems to recognize impracticalities on counting ED patients who may move quickly in and out of the hospital and may not receive a level of services that would qualify the hospital under meaningful use, by limiting numerator and denominators to patients actually receiving ED services.  Although this guidance helps, our subscribers have asked us to research a few additional questions to help stay in compliance.

 

• Question 1: Do we include all inpatients or only inpatients admitted through the ED? 

Choosing Observation Services Method has no impact on defining how Inpatient visits will be measured.  It does define a population of patients (ED patients who have been admitted to IP wards), for whom the provider must include all visits and activities in numerator and denominator.  Since all these patients should be included in inpatient reporting (independently of Observation Services Method) the practical matter here seems to be the requirement (and opportunity) to include documentation of services performed during the ED portion of the encounter for those patients. 

 

• Question 2: For the observation patients, do we include all observation service patients, or only those who present through the ED?

In providing a choice of using Observation Services patients (as a subset of ED Patients), CMS seems to be reacting to some of the practical problems of reporting on a broader, more volatile patient population of everyone who presents to the ED.  We do not think their intent is an across-the-board substitution of Observation Services Patients for ED patients, so the safest option seems to be making sure your reporting correctly identifies those Observation Services Patients who initially presented to the ED, and as in the prior question, accounting in the numerator for all documentation occurring in the ED setting on those patients.  Any Observation Services patients coded with a Place of Service Code other than 21 or 23 (Inpatient or ED) would be excluded from your numerator / denominator (except for those initially presenting through the ED). 

• Question 3: How does the selection of Observation Services Patients impact Clinical Quality Measure calculations?
  • First, the language of FAQ 10126 addresses numerator and denominator of Meaningful Use Objectives explicitly.  In the Final Rule for EHR Incentives, CMS consistently lists those specific Objectives, and identifies Clinical Quality Measures separately. 
  • Secondly, the Clinical Quality Measures contain specific calculations, data elements, and exclusion rules via independently-published HITSP specifications. 
  • Finally, in a separate related FAQ # 10883 issued on December 22, 2011, CMS answers a question  regarding  CQMs ED-1, ED-2, and Stroke-4, on how should hospitals define an Emergency Department patient since the UB-04 data set referred to in the HITSP specifications no longer provides this information?  In this FAQ, CMS recommends that hospitals use the data element 'ED Patient', defined as any patient receiving care or services in the Emergency Department (without comment regarding Observation Services Method). 
  • Therefore, while none of these statements are definitive, we believe the trend is to isolate Observation Services Method calculations to Meaningful Use Measures, independently of Quality Measures. 

 

So, the bottom line is that it is probably prudent to test following 12 reports in your Certified EHR to validate that they are correctly counting ED patients consistently, based on your decision on using Observation Services Method:

• CPOE
• Record Demographics
• Problem List
• Maintain Active Medication List
• Maintain Active Medication Allergies List
• Record Vital Signs
• Record Smoking Status
• Provide patients with an Electronic Copy of their Health Records  Upon Request
• Provide Patients with an Electronic Copy of their Discharge Instructions Upon Request
• Use Certified EHR Technology to Identify Patient-Specific  Education Resources
• Perform Medication Reconciliation
• Provide Summary Care Record for each Transition of Care

All other reports would fall under either Clinical Quality Measures, or require a Yes / No attestation (which would be probably be independent of your ED patients), or explicitly exclude ED patients in their definition. 

Inpatient Self-Certification Trends

In light of GE Healthcare’s recent announcement of potential errors in their certified EHR’s reporting functions, it seems reasonable to expect that more hospitals will be re-evaluating their own EHR’s reports, and in some cases, self-certifying that capability. And we recently had an interesting question from one of our subscriber hospitals that just finished a broader self-certification initiative of their overall EHR technology inventory. This group didn’t build their own, but assembled best-of-breed tools from multiple vendors. By picking and choosing components, they satisfied clinical staff and managed costs, but were unable to take advantage of all the vendor-provided certifications. This forced them into “self” certifying a select number of modules to meet the requirement of using a “complete” certified EHR.

We wondered about how many other hospitals were seeking self-certification, and for what functionality. A little research into the CMS web site (http://onc-chpl.force.com/ehrcert) listing organizations that have certified EHR software, answered some of those questions. Here’s what we found (as of 11/05/11):

1. How Prevalent is Self-Certification?

Only 18 hospitals (or hospital systems) have completed any level of self-certification.

2. What Self-Certification Strategies are Hospitals devising?

Those 18 hospitals have certified 28 unique “product bundles”. Most are certifying “Modular” rather than “Complete” EHR functionality with only 5 of 18 pursuing Complete Certification. Of those 5, we know a couple personally. In several cases, hospitals have their own internally-developed custom EHR’s, but in others, self-certification comes from a strategy of purchasing best-of-breed components. In some of these cases, the hospital has purchased a subset of a Vendor’s certified product, and by purchasing less than the Vendor’s full suite, invalidates the Vendor’s certification.

3. What Functionality is being Self-Certified?

What we expected to see, was a preponderance of hospitals self-certifying reporting functions of Clinical Quality Measures, and Automated Measure Calculation. While there is certainly a significant amount of self-certification of reporting involved, almost every Measure is represented in hospitals seeking modular (partial) self-certification.

4. How Successful are Certification Efforts?

Of those achieving modular certification, some appear to be attempting certification as complete EHR, and accepting partial certification when some components don’t pass … then re-submitting for additional testing at a later date. Of course, we don’t see those who have attempted and failed, but some hospitals show multiple certified versions of the same product, with earlier products containing less certified functionality.

5. What is the ATCB mix (Which certifying bodies)?

16 by CCHIT, 9 by Drummond and 3 by InfoGuard. Percentage-wise, this is almost identical to the mix of ATCB's used by the vendor community. In other words, no single ATCB has emerged as the entity of choice for self-certification activities. CCHIT has two hospitals who appear to have been through multiple iterations to meet their certification goals, and Drummond has one. Based on this limited data, but it appears all ATCB's are equally rigorous. It might be interesting to get some anecdotal or other data to learn a bit more.

So, to summarize there's not been much self-certification yet, there is little "pattern" in what content is self-certified, and it is being done by about the same mix of ATCB's as what is being certified by vendors. If you are considering self-certification, and want to talk to someone who has done it, scan the CHPL site, looking for hospital names and give the CIO a call. There are not many!

When is Certified Software not Really Certified?

Ownership of part of a Certified EHR might hurt you.  EHR's are certified by ATCB’s against a list of ONC-Generated certification criteria.  To become certified, a Vendor will submit a bundle of their own software to an ATCB for testing.  For some vendors, this “bundle” could be a single piece of software.  But more commonly, we find that vendors build and deploy their product by assembling modules from which a customer can pick and choose to compliment other products in the hospital (or EP) software inventory. 

If you are not careful, this practice might actually cause you to have to return your Stimulus Funds to CMS.  Ouch. 

Here’s how it happens

You’re buying an EHR from a vendor with a "complete" or "modular" Certified EHR Product.  As a good negotiator, you manage your costs by only purchasing the EHR Modules  you need.  Perhaps you already own Quality Reporting module, or plan on doing e-MAR next year.  So you save a lot of money by not purchasing capabilities that you won’t use yet. 

The problem is that when your new EHR vendor was certified, they included the modules you did not purchase in their testing bundle.  Since you own less than all of the components included in the Certification bundle, CMS will not recognize the validity of your product’s certification! 

You might not even be aware of this problem.  When you attest, you look up your vendor on the CMS Certified vendor site, get a certification number and include that in your attestation. 

A couple years later, a CMS auditor, reviewing your 2012 attestation, looks for documentation that you owned “certified EHR technology”, finds you short, and may take away your EHR Stimulus funding, along with penalties and interest. 

Here’s the quote from the ONC website addressing this issue:

“Stand-alone, separate components of a certified Complete EHR do not derive their own separate certified status based solely on the fact that they were included as part of the Complete EHR when it was tested and certified. The separate component(s) would no longer meet the definition of a Complete EHR, nor would it have independently demonstrated that it can still properly perform capabilities for which certification is required in the absence of the capabilities with which it was previously certified as part of the Complete EHR. Additionally, the separate component(s) would not satisfy the requirements of 45 CFR 170.450(c) related to the privacy and security testing and certification of EHR Modules.

This concept is similar to our treatment of integrated bundles of EHR Modules. We clarified in the Temporary Certification Program final rule (75 FR 36191) that EHR Modules, once certified as part of a bundle, would not each separately inherit a certification just because they were certified as part of a bundle.”  ONC Question [9-10-005-1]

 

Here’s your protection

Draft a letter to your EHR vendor, and the ATCB where they were tested.  Don’t ask your EHR salesperson – they may not be aware of these nuances in the ONC portion of the CMS regulations.  Ask for a written listing of the vendor’s listing of all modules, components and supporting software that were included in the specific ATCB testing bundle associated with the certification number you are expecting.  Save the vendor’s written response in your Attestation Audit Proof Documentation Library, and match it up with a copy of your contract, showing that you have all the components included in your attestation.  

Now, if your documentation shows that you own all the software necessary, you are in good shape.  If you find shortfalls, your options will include purchasing those shortfall items from your vendor, or considering self-certification of your own bundle, including your EHR vendor’s components. 

Comparison of ONC's ATCB organizations for EHR Certification

With the passage of the HITECH Act in 2009, the phrase “meaningful use,” took on a much greater importance for physicians in the US. The ONC Authorized Testing and Certification Body (ONC-ATCB) program was thus created to certify that electronic health record (EHR) software was capable of meeting meaningful use requirements and allow physicians using it to be eligible for government incentives.

So who are the ONC-ATCBs, the groups that certify these EHR software applications? There are currently six groups that are authorized to certify EHRs, and certification from one group means the same as any other’s. So what differentiates the six ONC-ATCBs?

Who are the Six ONC-ATCBs?
The six groups currently authorized to certify EHRs are: Drummond Group, CCHIT, InfoGard, ICSA Labs, SLI Global Solutions, and Surescripts.  All groups will go through similar procedures with EHRs that wish to be certified, including:

(1) Reviewing the EHR application

(2) Pre-testing support

(3) Testing (live and via remote conferencing)

(4) Results reviewed by an internal panel

The ONC-ATCBs must follow the guidelines presented by the NIST, but they are allowed the freedom to present the test guidelines to the EHR vendors as they wish.  This is one of the differentiators that EHR vendors should look into when selecting an ONC-ATCB.

The Six ONC-ATCBs Don’t Cost the Same
Another important differentiating factor between the six groups is the pricing of their services. For reference, the general pricing structure of four of the six groups is listed below:

CCHIT: $34,300 for ambulatory certification, and $32,550 for inpatient certification. Modules are about $7,000 plus $650 to $2,000 based on complexity,

Drumond Group: $19,500 for ambulatory and inpatient certification. Module pricing ranges from $1,000 to $6,000 per module (larger discounts for multiple module testing).

InfoGard: $19,900 for ambulatory certification, and $19,400 for inpatient certification. Module pricing for privacy and security modules plus one additional module is about $5,000.

SLI Global Solutions: $20,000 for ambulatory and inpatient certification. Module pricing ranges $1,000 to $6,000 per module (larger discounts for multiple module testing).

ONC-ATCBs Come From Different Software Testing Backgrounds
The six bodies that certify EHRs come from different backgrounds in software testing. The Drummond Group, for example, has a background in testing software in other fields, and has transitioned to medical electronic health record software. CCHIT, on the other hand, has been testing EHRs for over six years. ICSA Labs has experience testing mostly IT security software, and InfoGard has a similar background—being the first computer security testing group accredited by the NVLAP. SLI Global also has a number of years experience testing software. Surescrips, on the other hand, is the leading ePrescribing network in the US, and has been authorized to test and certify e-prescribing modules.

This guest post is provided by Software Advice, which provides reviews and comparisons of electronic medical record (EMR) software. You can view their website here. For more information on the ONC-ATCBs and the certification process, check out this article: Uncovering the ONC-ATCBs: What’s the Difference?

Michael Koploy, Software Advice

 

Verify Your Certified Software?

How does Regulatory Compliance map against Clinical Practices Comliance? 

As providers move towards tracking their Meaningful Use Progress, we are starting to see instances where Certified Software does not fulfill all the needs of regulatory compliance.  Actually, it is pretty impressive the degree to which the vendor world has responded to Meaningful Use.  Vendors who have been around for years, building in clinically sound EHR capabililties have had precious little time (in software development terms) to add in Regulatory Tracking functionality. 

Let's face it.  Little (maybe even nothing) in Meaningful Use Regulations creates clinically usable or necessary functionality that the vendors didn't already envision and have in their software.  ARRA didn't create the concept of CPOE, Quality Reporting, Problem List Tracking, or any measure Hospitals or Ambulatory docs are required to track for EHR Stimulus.  But what ARRA does in many cases, is add functionality that is necessary to track ARRA.  Here's a couple examples:

Emergency Department Software: A couple of our hospitals use a certified EHR by a long-time vendor providing successful ED software.  This particular product tracks lab results as structured data for all patients for which the ED receives results.  Of course the results are often delivered a couple days after the patient has left the ED.  Because the volume of these reports is quite high, and the clinical need to retain the specific results is low, the system automatically purges unreferenced data after 30 days retention.  Clinically valid.  ARRA Oops.  (ARRA requires a 90 day reporting period, during which hospitals must aattest to having this data for 40% of all EHR Patients).  Note that the EHR in question is certified, since the test did not "stress" for volume.  Here's a case where a hospital could attest to a requirement, but a subsequent by-the-book auditor could feasibly find the hospital non-compliant.

Tracking patient requests: Two specific measures require that providers give patients electronic copies of EHR data upon request.  One of our hospitals is using certified EHR which does a nice job of selecting out data and providing electronic versions in a couple formats for patients.  But this particular (certified) software product lacks the capability to log those requests from patients!  The measures state that for 50% of the patients who request it, the provider must generate electronic results. Oops again.  Now, this is a first-class vendor, and it is a good bet that they will provide tools to their customers pretty soon.  But until then, users will have to come up with a sub-system to track these requests, and satisfactory responses.  On the other hand, we don't think this kind of request is likely to generate much volume in the near future ...

So here's the point.  ARRA creates the need for vendors to incorporate into their software functionality that is not clinically necessary, but is required for administration of the ARRA program.  And this is the arena where well-intentioned providers might stub their toes without even knowing it.  It seems prudent that providers have a process, and maybe even some third party tools, to help keep track of each individual requirement, and the results of your progress against not only clinical, but also regulatory compliance. 

Jay Fisher |@JayRFisher

Caveat Emptor! Certified EHR might fall short on Reporting

Your Certified EHR will do everything you need, right?  And if it does not, it is the vendor's issue, right? 

Kind of. 

Here's an interesting extract from the criterion by which EHR software is certified for the process of Automated measure calculation (170.302 (n)). The regulations state that this criterion requires 

"For each meaningful use objective with a percentage-based measure, electronically record the numerator and denominator and generate a report including the numerator, denominator, and resulting percentage associated with each applicable meaningful use measure."

Clear enough.  But look at the detail instructions for actually validating that this occurs, and you may be surprised by the minimum requirement:

The Vendor provides the test data for this test procedure.

This test procedure is organized into two sections:

- Record - evaluates the capability to electronically record the numerator and denominator for each meaning use objective with a percentage-based measure
   o If the Vendor indicates that the EHR automatically records the numerator and denominator
for the measure, the Tester proceeds to the Generate Report step below.
   o If the Vendor indicates that the EHR does not automatically record the numerator and/or
denominator, the Tester uses Vendor-identified functions and Vendor-supplied
numerator/denominator values to enter numerator/denominator information into the EHR.

- Generate Report - evaluates the capability to generate a report that includes the numerator,
denominator, and resulting percentage associated with each percentage-based meaningful use
measure
   o The Tester generates a report that includes the numerator, denominator, and resulting
percentage associated with each percentage-based meaningful use measure
   o The Tester validates that the report is generated and is accurate and complete based on
Vendor-supplied data 

Ok let's read between the lines here.  First, the vendor is only required to calcualte and display the numerator, denominator and any associated percentage.  They are not required to provide any detail reporting to support or prove this percentage.  Prudent vendors probably will but certification is not a guarantee. 

Secondly, if the vendor's software does not automatically calcualte the numerator and denominator, they can still pass the test!  All they need do, is have the ability to enter the numerator and denominator into their system, and from there calculate a percentage. 

We derive two action items from this set of observations. 

1. Quickly figure out how your vendor's software works
2. Quickly find the reporting in your vendor's software that shows the details associated with each measure.  If the report does not exist (and it is not required to exist), they you might want to get your Business Intelligence Team on it. 

Jay Fisher | @JayRFisher

 

Guidelines for Attestation with Multiple EHR Technologies

We were chatting recently with a tester from one of the  ATCB's who issue EHR software certifications on behalf of CMS.  As you know, the first step towards compliance with the ARRA laws enabling hospitals to receive EHR stimulus funds is in actually owning certified EHR software.  Our friend there has been involved in testing EHR's for the purpose of "self-certification".  Self certification becomes a necessity more often than you might imagine ... but that's a topic for a different day. 

At this particular ATCB, we heard that a majority of the hospitals presenting themselves for self certification were doing based on a combination of multiple EHR technologies.  What an intriguing set of pragmatic issues this raises!  Let's explore a few, with some ideas on solutions. 

1. Roll up of Measures - You'll need some way in which to aggregate numerator, denominator and the resulting percentage across multiple EHR's, when it comes time to attest. 
2. Aggregation of "Audit Proof" - as we've discussed elsewhere, attestation is probably a lot easier than providing detail documentation acceptable to a skeptical CMS auditor, who can show up on your doorstep for up to 6 years after attestation.  Depending on CMS' perception of program performance, these auditors may be inclined to merely check that your technology can calculate a percentage - or may be inclined to evaluate detailed lists of unique patients under the circumstances of each unique MU measure.   Risk-adverse organizations will probably create reporting across multiple EHR's to pull the requisite details, with a track-back to the specific EHR in which patients are maintained. 
3. Yes/No Attestations - Counting Core and Menu items, there are 9 measures for which you can attest by merely saying "yes" or "no".  The conservative approach is to make sure that for each of these measures, you should be prepared to defend a "yes" attestation across all EHR's in your inventory.
4. Denominator for Measures that count "All Patients Maintained in Certified EHR technology" - similar to Yes/No attestations, it seems prudent (under a conservative approach) to account for all unique patients across all EHR's rather than just a single core product. 
5. Denominator for Measures that count "All patients", regardless of whether they are maintained in Certified EHR - Patients in your OB ward whose records never make it to the core inpatient EHR system probably are one example - particularly if they are maintained in a standalone EHR that has not been certified.  When calculating this type of measure, and there are several, make sure you isloate these "non-certified EHR" patients and count them appropriately, as you conduct your measure rollups for hospital-wide attestation and audit proof. 
6. EHR Certification Number - This one stumped me at first, but there is a simple answer.  When a provider signs up to attest to Meaningful Use, the attestation site asks if you have a certified EHR.  And it provides a field in which you report yours.  But there is only one field!  Here's how it works.  On the Certified EHR Product List (CHPL) website at http://onc-chpl.force.com/ehrcert ... Select the first EHR in your inventory, and add it to your shopping cart.  Find each of the other certified products, and add them as well. When you check out, CMS will aggregate these products together and give you a single, aggregated certification number usable in your Attestation.  If you've self certified one or more products, they will be on the CHPL site as well, and will simply be one of the selections you make.  

I'll bet there are other practicalites we've not investigated here.  Share your thoughts, and between us, we'll come up with a comprehensive point of view! 

Jay Fisher | @JayRFisher

 

 

Is a provider required to own a Complete EHR? - Not as straight forward as it may appear

Based upon a recent issuance by ONC, we are revising our position on the need to implement software to support all certification criteria to be compliant with the HITECH law of using certified EHR technology. It is necessary to have certified EHR technology that addresses all certification criteria, even those criteria which support meaningful use objectives whihch the provider is not submitting to CMS. See http://healthit.hhs.gov/portal/server.pt/community/onc_regulations_faqs/3163 for the FAQ release. The specific item is number 17# :

Question [9-10-017-1]: Under the Medicare and Medicaid EHR Incentive Programs Final Rule, eligible health care providers are permitted to defer certain meaningful use objectives and measures and still receive an EHR incentive payment. However, it is our understanding that in order for us to have our EHR technology certified, we must implement all of the applicable capabilities specified in the adopted certification criteria regardless of whether we intend to use all of those capabilities to qualify for our EHR incentive payment. Is our understanding correct?

Answer:

Yes, this understanding is correct. The flexibility offered as part of the Medicare and Medicaid EHR Incentive Programs Final Rule is not mirrored in the Initial Set of Standards, Implementation Specifications, and Certification Criteria Final Rule because we believe that it is important to accommodate eligible health care providers’ ability to achieve meaningful use. We recognize that in some circumstances an eligible health care provider may not know which meaningful use measures they will seek to defer until they begin implementation and in others an individual provider (even within a specialty) will want to choose different measures to defer based on their local situation and implementation experience. Thus, in order to possess EHR technology that meets the definition of Certified EHR Technology, it must be tested and certified by an ONC-ATCB to all applicable certification criteria adopted by the Secretary.

Physician (or hospital) - "Certify" Thyslf?

By now, most of you have read or been exposed to the Final Rule for the Establishment of the Certification Program for Health Information Technology. In essence, this program established the  principles to operationalize the process to "certify" EHR applications so they can help qualify a hospital or Eligible Provider for the EHR Incentive Program contained in the ARRA Stimulus law. At the centerpiece of the process are the ATCB's (Authorized Testing and Certification Bodies) which conduct the actual certification assessment against the published certification criteria (see the Final Rule for Initial Set of Standards, Implementation Specifications and Certification Criteria for Electronic Health Record Technology). The ATCB's will certify complete EHR's or EHR modules ( the individual ATCB that seeks EHR module testing and certification must specify which modules it will test and will be limited to those modules).

But who will be seeking this certification? Certainly software development companies which market and sell complete EHR's and EHR modules will be a prime "user" of this certification process offered by the ATCB's. However, there will also be a portion of the health care system that will decide to seek certification for their particular EHR application "suite". You ask why wouldn't these health care systems rely on the software vendor(s) who they purchased the EHR applications from? There are several factors which will drive these health care systems to "self' certify:

1. Old versions of vendor software - vendor may not be interested in expending resources to get "back versions" certified. Also, the health care system may not want to upgrade to "certified" version due to cost - both out of pocket and personnel time needed to upgrade
2. Incomplete set of applications from one EHR vendor - even if the EHR vendor has a Complete EHR certified, it may not be used by the health care system due to preferences, existing modules already in place etc.
3. Multiple campuses using different applications - due to age of when EHR components were installed, strong likelihood there will be differences between campuses.

Given these reasons, there is a strong likelihood that some health care organizations will explore "self" certification for parts (or all) of their EHR technology. Some will view this alternative as more cost effective, less disruptive and faster to gain certification status. At this point, ATCB's are publishing prices to self certify at prices around $35,000 for a complete EHR, and much lower prices for individual Certification Criteria (Modules, in CMS-speak).  Although there will be work involved in preparing for and assisting in the testing and certification process, this effort may be less than upgrading to a vendor's "certified" version of the software.

What are the Definitive Sources for HITECH Stuff?

There's a lot of data about the ARRA HITECH law, Meaningful Use, Vendor Certification, blog sites, online magazines, websites ... and so forth!  We read some of that second hand data for useful analysis, a sense of what the industry is thinking and how it appears the laws and regulations might be adopted. 

But in the end, what really matters is the source material.  We thought it might be useful to provide a quick reference to the underlying sources.  Or at least a single place you can go when trying to organize which document contains which data for which audiences.  The following table might help:

Document Title	Content and Meaning	Link	Pages
42 CFR Parts 412, et al. Medicare and Medicaid Programs; Electronic Health Record  Incentive Program; Proposed Rule	Definitions, for providers, on how to achieve Meaningful Use of EHR.  Published in Federal Register	http://tinyurl.com/ygfrt8b	169
Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology; Interim Final Rule	Draft of Criteria by which EHR Vendors will be certified.  Published in Federal Register	http://tinyurl.com/yc5orpd	34
45 CFR Part 170 Proposed Establishment of Certification Programs for Health Information Technology; Proposed Rule	Draft of temporary and permanent rules by which Certification processes and criteria will be administered, and processes by which certifying organizations will be selected and managed.	http://tinyurl.com/yhzxz2b	47
H.R.1 American Recovery and Reinvestment Act of 2009 (Title XIII subsection titled HITECH is the relevant portion for Healthcare IT)	The bill passed by house and senate, and signed into law in February of 2009.  This is the source by which regulations are interpreted.	http://tinyurl.com/bpg4vl	220

Of course, there is the period of public comment that has passed for the provider side meaningful use materials, and for others, public comment is still in play.  In a conversation yesterday, we learned an interesting observation:

Federal Regulations, once published as Interim Final Rule, or Proposed Rule, cannot be increased.  In other words, public comment may lessen the rigor or impact of these documents, but cannot result in requirements more stringent than what was originally published. 

Of course, we can't say for a while yet what "lesser" rules might exist.  But it is useful to know that the contents of the above table define a "most rigorous case" scenario!

Jay Fisher | @JayRFisher