PQRI XML Submissions Required for Certification

One of the challenging aspects of Complete EHR Certification is the PQRI XML needed for submission of quality measures to CMS.

There are 15 required hospital quality measures but the 2 Emergency Department measures are stratified for reporting and must be presented in 3 different ways, so a total of 19 PQRI XML files need to be generated for Complete EHR Certification of hospital systems.

Each of the files uses identical XML.  The only parameters that change are

pqri-measure-number which is set to the NQF measure being submitted such as NQF 0435 (see the graphic above for the list of NQF hospital measure names)

eligible-instances which is the number of patients who meet eligibility requirements to be measured for the time period being submitted

meets-performance-instances which is the numerator of the measure i.e. those patients who had the appropriate treatment or outcome

performance-exclusion-instances which is the number of patients removed from eligible-instances for specific clinical reasons.  The denominator of the measures is always (eligible-instances minus performance-exclusion-instances)

performance-not-met-instances which is the number of eligible patients who did not have the appropriate treatment or outcome.  It can be calculated as (eligible-instances minus meets-performance-instances minus performance-exclusion-instances)

reporting-rate which is a multiplier i.e. for a percentage the reporting rate is 100

performance-rate which is the calculated performance level and is equal to meets-performance-instances/(eligible-instances minus performance-exclusion-instances)*reporting-rate

Let's do a real example so this becomes clear.   If we want to create PQRI XML for NQF Measure 0435, which is "Ischemic stroke patients prescribed antithrombotic therapy at hospital discharge", we need to go the HITSP TN906 document and gather the definition from pages 48-52

In this case,

eligible-instances is defined as "Patients admitted to and discharged from the hospital for inpatient acute care with a diagnosis of ischemic stroke (ICD9 433.00-438.99)"

meets-performance-instances is defined as "eligible-instances patients prescribed anti-thrombotic therapy(page 355-358 of HITSP specification) at hospital discharge"

performance-exclusion-instances is defined as
"Patients with age < 18
Patients with length of stay >120 days
Patients with comfort measures only documented
Patients enrolled in clinical trial
Patients admitted for elective carotid intervention
Patients discharged/transferred to another hospital for inpatient care
Patients who left against medical advice or discontinued care
Patients who expired
Patients discharged/transferred to a federal healthcare facility
Patients discharged/transferred to hospice
Patients with a documented reason for not prescribing anti-thrombotic therapy at discharge"

Suppose that 110 patients are eligible, 80 received anti-thrombotic therapy, and 10 were excluded.

performance-not-met-instances would be (eligible-instances minus meets-performance-instances minus performance-exclusion-instances) or  110-80-10=20

performance-rate would be meets-performance-instances/(eligible-instances minus performance-exclusion-instances)*reporting-rate or 80/(110-10)*100 = 80%

The PQRI XML generated would be

<submission xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:noNamespaceSchemaLocation="Registry_Payment.xsd" type="PQRI-REGISTRY" option="TEST" version="1.0">
  <file-audit-data>
    <create-date>31-01-2011</create-date>
    <create-time>04:22</create-time>
    <create-by>Your Organization Name Goes Here</create-by>
    <version>1.0</version>
    <file-number>1</file-number>
    <number-of-files>1</number-of-files>
  </file-audit-data>
  <registry>
    <registry-name>Your Application Name Goes Here</registry-name>
    <registry-id>123456</registry-id>
    <submission-method>C</submission-method>
  </registry>
  <measure-group ID="X">
    <provider>
      <npi>1111111112</npi>
      <tin>123456</tin>
      <waiver-signed>Y</waiver-signed>
      <encounter-from-date>2010-01-01T00:00:00</encounter-from-date>
      <encounter-to-date>2010-12-31T00:00:00</encounter-to-date>
      <pqri-measure>
        <pqri-measure-number>NQF 0435</pqri-measure-number>
        <eligible-instances>110</eligible-instances>
        <meets-performance-instances>80</meets-performance-instances>
        <performance-exclusion-instances>10</performance-exclusion-instances>
        <performance-not-met-instances>20</performance-not-met-instances>
        <reporting-rate>100.00</reporting-rate>
        <performance-rate>80</performance-rate>
      </pqri-measure>
    </provider>
  </measure-group>
</submission>

For the ED measures, which capture time measurement rather than patient counts, you need to create 3 files for each measure, stratified by

1. All patients that were admitted via the ED, excluding the ICD-9 range for PSYCH (ICD9 290-319) and Observation Patients.

2. All observation patients that were admitted via the ED, excluding the ICD-9 range for PSYCH (ICD9 290-319)

3. All psychiatric patients that were admitted via the ED, including only the ICD-9 range for PSYCH (ICD9 290-319)

eligible-instances is recorded in the same way as other measures.

meets-performance-instances is used to record the median time data.

performance-exclusion-instances, performance-not-met-instances, reporting-rate, and performance-rate are set to zero.

Hopefully this explanation makes it easier for hospitals and vendors to create the necessary PQRI XML for certification.

Cool Technology of the Week

The iPhone and iPad have provided a remarkable platform for mHealth, empowering consumers to manage their wellness, communicate with clinicians, and support treatment workflow via smartphones.

One of the coolest examples is Walgreens new application which supports automated medication management.

Each medication dispensed or sold at Walgreens has a bar code. After registering the application to your nearest/preferred Walgreens pharmacy, you simply scan the label using the iPhone/iPad camera and it automatically uploads to the Walgreens you’ve chosen. There are alerting functions for all parts of the prescription life cycle.   You link your transactions to a credit card on file, drive up to the Walgreens pick up window and they dispense your prescription. The pharmacist asks if you have any questions, just as if  you went into the store.

Walgreens summarizes their application features as:

Pharmacy
•New Express Refills by Scan*: Just scan the barcode on your prescription bottle for instant refills
•Order refills from your account history using your device
•Secure access to your prescription history from the palm of your hand
•Enter a prescription number for refills

Photo
•Upload multiple images simultaneously and pick them up at a local Walgreens in about an hour or have them shipped directly to you

Shopping Features
•New Weekly Ad interface featuring cover flow
•Add items to your shopping cart directly from our local Weekly Ads
•Check product availability and pricing at any store
•Flu Shot and Take Care Clinics locator

Using a smartphone as a bar code reader to support medication management workflow and e-commerce.  That's cool!

The Birds in my Backyard

This week, we've had bitterly cold weather in the Northeast.   As Wellesley's unofficial weatherman,  I've been tracking temperatures as low as -5F (without wind chill) and -20F with windchill.

I've provided extra safflower, sunflower, and thistle to the winter birds that frequent our yard - Carolina Wrens, Juncos, Nuthatches, Flickers, Doves, Hairy Woodpeckers, House Finches, Cardinals, and Blue Jays.

We've provided a source of drinkable water by heating a bird bath.

An interesting side effect of becoming the food, water and shelter magnet for birds in our neighborhood is that we've also attracted 3 birds of prey - 2 Red-Shouldered hawks and 1 Coopers hawk (above).

While writing about Meaningful Use this weekend, I looked up and saw a cardinal eating safflower.   I looked up again and saw a Red-Shouldered hawk eating the cardinal.

Although I'm a vegan I can appreciate that this is the food chain in action and respect it.

Winter is a remarkable time for mindfulness - to steep yourself in the events of the moment, watch the birds against the snow, and appreciate living in the present.

General Principles of a Universal Exchange Language

I've written several posts about the President's Council of Advisors on Science and Technology (PCAST) report on Health Information Technology.

Between January and April, the PCAST Workgroup will think about the high level concepts in the report, which I believe can be distilled into 3 major themes

1. Increase the priority of interoperability to facilitate coordination of care and to enhance research capabilities.
2. Establish a Universal Exchange Language based upon an XML-style approach for exchanging individual data elements.
3. Create a supporting exchange infrastructure that includes a data-element/record locator service along with appropriate privacy and security controls.

I've recently thought a great deal about #2 - the Universal Exchange Language.    I've posted Sean Nolan's examples and provided a briefing about existing approaches to data exchange used on the web.

Before jumping into XML formats and comparisons of existing healthcare standards, I believe we should first define the general characteristics of the ideal Universal Exchange Language.

We should be guided by the HIT Standards Committee's Implementation Workgroup principles for evaluating all future standards work:

Keep it simple.
Don’t let “perfect be the enemy of “good enough.”
Keep the implementation cost as low as possible.
Design for the little guy.
Do not try to create a one-size-fits-all standard.
Separate content and transmission standards.
Create publicly available vocabularies & code sets.
Leverage the web for transport (“health internet”).
Position quality measures so they  motivate standards adoption.
Support implementers.

If I were to invent a Universal Exchange Language using nothing but these guiding principles and my intuition as a doctor and CIO,  I would include the following:

1.  High signal to noise ratio  (some existing standards have significant overhead for every clinically relevant data element).

2.  Easily human readable (by a developer, not necessarily an end user) and computable.

3.  Easy to create, easy to parse.

4.  It should be trivial and clearly understandable how to implement basic exchange such as sending and receiving a medication list, a problem list and an allergy list.

5.  There could be multiple sources of ontology/concept information as long as the receiver of the information understands how the sender packaged and defined the data elements.

6.  To the extent that ontologies are used, they should be viewed as pure notation by developers.  Developers should not need to even understand what an ontology is to be able to understand the content.  As with #5, developers should only need to be able to write code that will consume the metadata that links the content with the context defined in the ontology.

7.  It should be trivial to add additional metadata or additional data without impeding the ability to send and receive the basics.

8.  Data elements should be separable from the document, but we have to be realistic about this, since Problem Start Date really needs to be associated with a Problem Name to be useful.   We could define "data atomic" as the smallest unit of data that makes sense within the context defined by the associated metadata.

9.  An implementation guide should completely define the required and optional data and metadata elements for a given purpose.  Implementers should not have to open a dozen different Standards Development Organization products and implementation guides to understand how to create a message.

10.  Innovators should be free to think about optimal ways to solve this problem without being overly constrained by existing implementations.  Since health information exchange is in its infancy, strict compatibility with previous approaches is not our highest priority.

The PCAST report is likely to be a catalyst for rich discussion.   I look forward to the work ahead to offer ONC options for including PCAST principles in its existing programs and strategies.

Reflections on the Certification Experience

On Friday, January 21,  2011, Beth Israel Deaconess Medical Center completed the certification of its enterprise EHR technologies via the CCHIT EHR Alternative Certification for Hospitals (EACH) program.   Here's the press release.  As I've written about previously, BIDMC (like many academic health centers) has a combination of built and bought technologies that collectively provide interoperability, clinical functionality, and security.   We demonstrated all our Intersystems Cache-based hospital systems and our Microsoft SQL Server-based business intelligence systems.

The process was rigorous, requiring us to follow over 500 pages of scripts and implementation guides in a single 8 hour demonstration.

The staff at CCHIT were remarkable, educating us about the NIST script requirements, emphasizing the need to prepare, and clarifying aspects of the NIST scripts that were ambiguous or seemed clinically unusual.

NIST did a great job creating test scripts rapidly enough to enable vendors and hospitals to certify systems in time for meaningful use attestation.  However, there are a few oddities in the scripts that are only discoverable during pilots in real hospital and eligible provider clinical settings.   I strongly recommend that for all future certification, NIST pilot their scripts before they are issued for general use.

Major lessons learned include:

*If hospitals apply for complete EHR certification, adding new functionality to fill functional gaps may take months.   Once gaps are filled, I recommend that hospitals devote at least 2 weeks and 5 FTEs to reviewing the scripts, analyzing the best way to show the necessary functionality, and practicing the demonstration.

*The most challenging aspects of certification are interoperability and security.    Interoperability requires  data entry of the necessary information to support the transactions specified in the Standards Final rule: immunization submission, syndromic surveillance, reportable lab, patient summary data import, and patient summary data export.   During certification, each of these data streams will be thoroughly analyzed for compliance with NIST validation tools and/or manually inspected.

*Several of the NIST scripts require data entry that seems clinically unusual.    For example, you must place a CPOE order for Darvocet for pain control, even though Darvocet has been removed from the market by the FDA.    Many of the medications included in the scripts are unusual brand name medications that may not be on a hospital's formulary.   One data set in the Reportable Lab script requires that you send a public health entity information about an infection the patient does NOT have  (Stool Culture with a negative result for Shigella).

*The NIST scripts require that you demonstrate data entry of information that is not normally entered by clinicians in a hospital.   The typical workflow for labs is that they are ordered from an external provider (Quest, Lab Corp) or processed by internal lab systems then inserted into the EHR via an HL7 transaction.   The NIST scripts should be revised to clarify that labs should only be shown, not entered.    Diagnosis and Procedure codes are typically created by Health Information Management after discharge and are sent from a Utilization Review system to the EHR via an HL7 transaction.  The NIST scripts should be revised to clarify that data elements not entered by the clinician should only be shown, not entered.

*The NIST scripts require demonstration of functions that may not be part of standard clinical workflow.   During certification, I wanted to demonstrate live transmission of transactions to the Massachusetts Department of Public Health and Boston Public Health Commission.   Neither of these real public health transmissions were acceptable because the NIST security script requires the demonstration of encryption and hashing in real time.   This is equivalent to not trusting the HTTPS in your browser and requiring browsers to display the actual encryption taking place for every web page retrieved.  The NIST scripts should be revised to enable attestation of the use of FIPS compliant encryption for Stage 1.   Hopefully for Stage 2, there will be enough specificity in transport standards so that the test can be accomplished by submitting data to a NIST specified website that illustrates adherence to the transport standard (NHIN Direct, NHIN Connect etc.)

Here are my detailed observations about the NIST scripts in the order of certification demonstration:

Interoperability
170.302 (k) Submission to immunization registries - This is a great script!  The clinical examples are accurate and are typical of the data elements captured in the real world.   The NIST validator tests real HL7 2.5.1 transactions and the implementation guide is very clear.

170.302 (l) Public health surveillance - This is a good script.   There are no specific examples to enter.   The only issue is that there is no NIST validator for the HL7 2.5.1 generated.   This is because of a mistake in the original Standards and Certification Final rule that specified an implementation guide for Disease Reporting, not Syndromic Surveillance.   A revision to the rule removed the original implementation guide but did not a specify a new one, Hence there is no implementation guide to certify against.   This is not a NIST problem,  but a regulatory problem that should be fixed soon.

170.306 (g) Reportable lab results - This is an odd script.  The examples are all "send out" labs from outside laboratories but the script requires demonstration of the data being entered.   How can you enter data provided by an outside lab?   This script should be revised to require only display of data received from an outside lab that was incorporated into an EHR.    The first sample data set for this script is reasonable - a lead level.   The other samples are more complex than is necessary for demonstration of public health reporting (three instances of the reason for reporting, a corrected result, and reporting of a disease the patient does NOT have - negative result for Shigella).   This is good example of a script that needed to be pilot tested before requiring its use.

170.306 (f) Exchange clinical information and patient summary record - this is a good script but it duplicates 170.306 (d)(1).   The first part of the script requires incorporation of a CCR and a CCD into the EHR in human readable form.   To do this, the appropriate Extensible Style Sheet (XSL)  reference needs to be inserted into the files and the CCD.xsl  and CCR.xsl need to be downloaded and placed in the same directory.   How is a hospital IT department supposed to figure this out? The appropriate style sheets should be included in the script with instructions on how to use them.

For CCD, insert

<?xml-stylesheet type="text/xsl" href="CCD.xsl"?>

For CCR, insert

<?xml-stylesheet type="text/xsl" href="CCR.xsl"?>

as the second line of the files.

The second part of the script is to generate a CCD based on complex data sets which include multiple elements that clinicians do not normally enter (hospital generated diagnosis and procedure codes).  The script should be revised to require only display of data, rather than entry, followed by CCD or CCR generation.  The CCD validator created by NIST uses the HITSP C83 specification which was published before the Standards Final Rule was developed.   HITSP C83 required problem lists to be coded in SNOMED-CT, but the final rule allows ICD-9-CM and SNOMED-CT.  You'll need to read Keith Boone's blog for step by step instructions to create a CCD with ICD-9-CM codes that passes validation.

170.306 (d)(1) Electronic copy of health information - this script should be eliminated because it is a duplication of 170.306(f) with slightly different data sets for generation of the CCD and CCR.

170.306 (i) Calculate and Submit Clinical Quality Measures - the script is fine, but the HITSP document which underlies it contains a few mistakes.  I feel responsible for this because I was the chair of HITSP at the time.   The exclusion and inclusion criteria for VTE-6 are incorrect.   They should be

Inclusion
Patients who received no VTE prophylaxis (HITSP Specification pages 367-370) prior to the VTE diagnostic test order date

Exclusion
Patients with age<18
Patients with length of stay>120 days
Patients enrolled in clinical trial
Patients with comfort measures only documented
Patients with VTE Present on arrival
Patients with reasons for not administering mechanical and pharmacologic prophylaxis
Patients without VTE confirmed by diagnostic testing

You'll also find the term anti-thrombolytic used throughout the document.   There is no such thing as an anti-thrombolytic.   It should be anti-thrombotic.

The HITSP quality measures specification was created before the Standards Final Rule was developed, so although both ICD-9-CM and SNOMED-CT are allowed by the Final Rule, the HITSP specification  defines the quality measures using only SNOMED-CT terminology.   This means that every vendor and hospital has to create their own mappings to ICD-9-CM for all the quality computations.  Here's what we used

Ischemic stroke (ICD-9-CM 433.00-438.99)
Hemorrhagic stroke (ICD-9-CM 430-432.99)
Atrial Fibrillation/Flutter (ICD-9-CM 427.31-427.32)
VTE (ICD-9-CM 453.40-453.42, 453.50-453.52, 453.6, 453.71-453.79, 453.81-453.89, 415.19, 416.2)
Psychiatric diagnoses  (ICD-9-CM 290-319)

I'll also make a controversial statement that several of the quality measures are too complex.   Many of the exclusion criteria are likely to have such a small impact on the measure that they should be eliminated.    (Was the patient  discharged/transferred to a federal healthcare facility?  Better exclude them.  Huh?).  I hope that future quality measures eliminate esoteric exclusionary criteria.

An unintended side effect of the quality measures is that they require changes in software and workflow not specified by Meaningful Use.   For example, in order to report on discharge medications for stroke and VTE patients,  you must implement electronic script writing at discharge to record the discharge medications and associated RxNorm codes for inclusion/exclusion.

Finally. the PQRI XML specification is ambiguous.   The ED measures only require 2 data elements, yet some validators require 6 data elements, with the last 4 set to zero.

Clinical
170.306 (b) Record demographics - Very well written, no issues.

170.306 (h) Advanced directives - Very well written, no issues.

170.302 (f)(1) Vital signs  - Very well written, no issues.

170.302 (f)(2) Body mass index - Very well written, no issues.

170.302 (f)(3) Plot and display growth charts  - Entering the data required for the demonstration is a lengthy process.  Best to revise the script to require only display of data, then graphing.

170.302 (g) Smoking status - The only challenge is that you must adhere to the CDC's smoking codes precisely (1=Current every day smoker, 2=Current some day smoker, etc.) despite the fact that the regulation lists only text values and doesn’t require the CDC numeric recodes.

170.302 (e) Maintain active medication allergy list - Very well written, no issues.

170.302 (j) Medication reconciliation - Very well written, no issues.

170.302 (d) Maintain active medication list  - Very well written, no issues.

170.302 (a) Drug/Drug and Drug/Allergy Interactions - The only challenge is that you must demonstrate how decision support can be disabled for drug/drug and drug/allergy interactions.  I can understand disabling selected drug/drug interactions to reduce alert fatigue, but I cannot think of a clinical reason to disable drug/allergy interactions.

170.302 (b) Drug formulary checks - Very well written, no issues.

170.302 (c) Maintain up-to-date problem list - Very well written, no issues.

170.306 (c) Clinical decision support - Very well written, no issues.

170.306 (a) Computerized provider order entry - The challenge is that the required medications are very odd.   Cefzil (cefprozil) suspension is likely not on most hospital formularies.  Darvocet has been removed from the marketplace by the FDA.   This script needs to be revised to reflect mainstream medications used in live healthcare settings.

170.302 (h) Incorporate lab results - Hospitals are likely to have their own internal laboratories.   The lab system and their EHR may share a common database.   If not, HL7 2.5.1 should be used to transmit data between a external lab systems and the EHR.   This script does not support integrated databases nor HL7 2.5.1 standards   Instead it requires that any structured format be sent from a lab system to the EHR. I'm not sure what policy or technology benefit such a demonstration creates.

170.302 (m) Patient specific education resources - Very well written, no issues.  Hospitals are free to use externally accessible resources such as UptoDate, Healthwise, or LabTestsOnline.org .

170.302 (n) Automate measure calculation  - Very well written, no issues.

170.302 (i) Generate patient lists - I believe that the spirit of the Policy and Standards Committee was to be able to demonstrate a single analytic query on EHR data.   The script goes much further than that, requiring filtering and sorting on problems, medications, and lab values.   I believe the script should be revised to allow a simpler demonstration of business intelligence using EHR data.

170.306 (d)(2) Electronic copy of health information - Very well written, no issues.  There is a great degree of flexibility to create and save discharge communications intended for providers.   There is no test data and no standards conformance testing.

170.306 (e) Electronic copy of discharge information  - Very well written, no issues.  There is a great degree of flexibility to create and save discharge communications intended for patients.   There is no test data and no standards conformance testing.

Security
170.302 (o) Access control - Very well written, no issues.

170.302 (t) Authentication - Very well written, no issues.

170.302 (q) Automatic log-off - Very well written, no issues.

170.302 (p) Emergency access - I'm truly confused by the intent of this test script.   I do not know of any Policy or Standards Committee intent to demonstrate the ability for users (not administrators) to override security controls and obtain access to clinical data.    We demonstrated it successfully, but I am unaware of this being a mainstream or desirable function in an EHR.

170.302 (w) Accounting of disclosures (optional) - We elected not to demonstrate this.  I'm not sure why optional requirements are included in certification.

170.302 (r) Audit log - The audit log script requires the ability to filter and sort the log by numerous criteria.   I am unaware of any Policy or Standards Committee intent to demonstrate advanced analytics on audit logs.

170.302 (s) Integrity - The final three security demonstrations are all very odd.   HIEs use data integrity protections and encryption to ensure data travels from point A to point B without modification.    The script requires demonstration of a test harness, not a live system, because encryption and hashing are invisible, just as HTTPS in your browser is invisible.   All three criteria should be revised to use attestation, not demonstration.
170.302 (u) General encryption - as above
170.302 (v) Encryption when exchanging electronic health information - as above

To restate my major points - CCHIT and the certification process are great.   NIST did a heroic job generating the scripts in a short time.   However, the scripts need to be piloted before they are placed in general use to avoid some of the challenges listed above.   I believe the scripts can be revised to substantially reduce the burden on vendors and hospitals without changing ONC/CMS rule compliance and HIT Policy/Standards Committee intent.

I welcome feedback on your own experiences with certification.   Meaningful Use and its associated processes will be the memories we tell our grandchildren about.

Obtaining Meaningful Use Stimulus Payments

Many clinicians and hospitals have asked me about the exact steps to obtain stimulus payments.

On January 3, 2011, CMS began registering clinicians for participation in meaningful use programs.    Every region of the United States has Regional Extension Centers which can help answer any questions. Here's an overview of the steps you need to take.

1.  Choose between Medicare and Medicaid programs.  If you qualify, Medicaid offers greater incentives and does not require you to achieve meaningful use before stimulus payments begin.
a.  To qualify for Medicaid, 30% of your patient encounters must be Medicaid patients. (20% for pediatricians)
b.  To qualify for Medicare, keep in mind that meaningful use payments are made at 75% of Medicare allowable charges for covered professional services in the calendar year of payment, per the payment maximums below:

Year 1  $18,000
Year 2  $12,000
Year 3  $8000
Year 4  $4000
Year 5  $2000

Thus, a total of $44,000 is available at maximum, but could be less if your allowable Medicare charges are less than

Year 1 $24,000
Year 2 $16,000
Year 3 $10,667
Year 4 $5333
Year 5 $2667

Also, if 90% of your Medicare charges take place in inpatient or emergency department locations, you cannot qualify for the meaningful use program.  This means that emergency physicians, anesthesiologists, radiologists, and pathologists generally cannot participate.  Some professionals may also find that they do not have enough Medicaid or Medicare charges to benefit from either program.

2.  Once you've chosen Medicare or Medicaid, you must register to participate
a.  You need a National Provider Identifier and password.   If you do not have one, go to the NPPES website.
b.  One you have a password, go to the CMS EHR Incentives Website and register as an eligible professional
c.  Two valuable resources include the Registration User's Guide and the CMS overview of the EHR incentive programs.

3.  The Meaningful Use demonstration period is 90 days beginning January 1, 2011 so the first date that you can attest to meaningful use of Certified EHR technology is April 1, 2011.   Note that the EHR technology you use must be certified by the time you attest.  You can begin your meaningful use reporting period using uncertified EHR technology as long as it is certified by the end of your reporting period.

Medicare payments will begin in May.  Medicaid payments are administered by states and will begin when state governments are ready to administer the program.  Some states are ready now and others will not be ready until August.  Remember that Medicaid payments start before meaningful use is achieved so there is no need to wait for meaningful use measurement and attestation for the Medicaid program.

Hospital requirements are similar
a.  First, you must locate the following, which your Revenue Cycle staff are likely to have:
CMS Identity and Access Management (I&A) User ID and Password.
CMS Certification Number (CCN).
National Provider Identifier (NPI).
Hospital Tax Identification Number.
b.  Go to the CMS EHR Incentives Website and register as an eligible  hospital
c.  The Hospital Registration User's Guide is a valuable resource

Here's a summary of the key dates for the program:

January 1, 2011 – Reporting year begins for eligible professionals.
January 3, 2011 – Registration for the Medicare EHR Incentive Program begins.
January 3, 2011 – For Medicaid providers, states may launch their programs if they so choose.
April 2011 – Attestation for the Medicare EHR Incentive Program begins.
May 2011 – EHR Incentive Payments expected to begin.
July 3, 2011 – Last day for eligible hospitals to begin their 90-day reporting period to demonstrate meaningful use for the Medicare EHR Incentive Program.
September 30, 2011 – Last day of the federal fiscal year. Reporting year ends for eligible hospitals and CAHs.
October 1, 2011 – Last day for eligible professionals to begin their 90-day reporting period for calendar year 2011 for the Medicare EHR Incentive Program.
November 30, 2011 – Last day for eligible hospitals and critical access hospitals to register and attest to receive an Incentive Payment for Federal fiscal year (FY) 2011.
December 31, 2011 – Reporting year ends for eligible professionals.
February 29, 2012 – Last day for eligible professionals to register and attest to receive an Incentive Payment for calendar year (CY) 2011.

I hope this clarifies your next steps.   May your stimulus funds flow quickly in 2011!

Cool Technology of the Week

Harvard Medical School is piloting digital whiteboards from Smart Technologies. 

It's not a giant iPad, it's more like a giant Wacom tablet paired with a computer and video projector.   The design works surprising well.

Here's the idea:

Mount a wall sized tablet with a reflective surface in the classroom.

Mount a special digital projector above the whiteboard

Connect the digital projector to a computer with HDMI audio/video

Provide digital pens - red/green/blue/black in special holders so that when a pen is removed from a holder, the whiteboard software knows that the red holder holds a red pen and all motions on the table should be in red.

Provide software that includes a pen/erase/capture selections

The end result is that web pages, applications and powerpoint are projected and teachers can annotate them with pens or their fingers.   They can capture and save their work for later display.

Early response of our evaluators has been very positive.   By combining a wall size tablet, screen, and projector with full audio/video interface into one package, we empower faculty to use all these educational technologies.

One great aspect of this is that the screen is separate from the projector, so it can be replaced if it is worn or damaged.   Creating a wall sized iPad would require replacing the display and the digitizer simultaneously.

Digital whiteboards for teaching.   That's cool!