Everything HITECH

Create your own CRAT for ARRA

OK, so we made up that acronym to represent Compliance Regulations Analytical Tool.  ARRA seems complicated because it is!  The Federal Register on Meaningful Use for Providers contains 276 pages of fine print, in three column format (in case you think that is not a lot, the very same content was originally published in a 872 page PDF).  To keep up with ongoing developments, you will scour the CMS FAQ site containing thousands of entries, over 200 of which are pertinent to the EHR Incentive Program.  Add in the EHR Vendor Certification Final Rule and your head starts to spin.  Once CMS Audit Programs start generating findings and interpretations, we can expect further elaboration based on those audit details. 

 So how should providers be collecting and organizing all this information? 

Action Item: Organize, analyze and communicate a steady stream of ARRA Data from multiple sources

Some people and some organizations are good at mentally organizing all the information that will assure their successful attestation to Meaningful Use – and ability to withstand a cynical CMS auditor who may appear over six years following attestation.  But most will find it useful to employ tools and techniques that institutionalize the research and analysis of a couple key internal or external experts.  This article describes a proven meaningful use model providers could emulate in their own operations.  It is based on a commercially available tool (Meaningful Use Monitor), but the concepts represent capabilities that could be built internally.  Here are the “ top 10” design components:

1. Deploy a database architecture - Databases provide structure that supports the complexity of ARRA, with better stability than spreadsheets.  Online databases facilitate real time communication / collaboration across multiple teams (clinical, IT, Administration).  And remember that you’ll need to monitor meaningful use every year, individually for the foreseeable future.  Just imagine all the spreadsheets …
2. Populate  Measure and CQM content directly from the Federal Register(s) – with references to specific page and column.  Every day, our Knowledge Center team answers questions from hospitals and clinics on Meaningful Use.  Even with that level of experience, knowing where to look, and in which Federal Register (there are actually two of them so far relevant to Meaningful Use), saves time and gives our answers a solid grounding in fact, supportable to even the most skeptical CFO or auditor.  Give your team this same edge. 
3. Tie each Measure and CQM to new and updated CMS FAQs - as soon as they are published.  In fact, you’ll need to periodically review “old” FAQ's, and update your knowledge center, since CMS sometimes updates historical items.  And when CMS Auditors hit the field, we expect further interpretations and elaborations for Meaningful Use Measures. 
4. Incorporate Community of Practice – Develop relationships with other providers, sharing your practical problems and solutions.  And use your CRAT to document your shared learning’s, associated with each Measure and CQM. 
5. Document your own standards and interpretations - for each Measure and CQM.  CMS actually states that providers will need to provider their own views in FAQ’s on specific measures.  As we progress through Meaningful Use, we find some regulations leave room for a range of possible interpretations.  Documenting your organization’s formal interpretation will save confusion, provide consistency, and explain to future auditors and reviewers the practicalities of why you took a given position.   
6. Link to PDF copies of your Certified EHR reports - on each Measure and CQM.  Once you have solid documentation of the unique set of requirements you’ve configured from Core and selected Menu objectives, start running the reports from your Certified EHR.   Then use your CRAT to assemble all those reports under one universally-accessible dashboard, complete with comments on progress or impediments your Meaningful Use Analyst needs to track and share. 
7. Link to workflows and policies - associated with each individual Measure and CQM.  Meaningful Use will be based as much on your policies and procedures, as on your technology.  Having all your policies and procedures in the same CRAT with the time-specific regulations and interpretations will help your process team and clinical staff be in compliance, and defend your position. 
8. Store long-term document repository - (explicit retention requirement of six years).  You don’t need to store interim EHR reports for the long term.  But once your organization (or individual EP) hits Meaningful Use over an appropriate reporting period, you’ll want a permanent snapshot of the state of your EHR’s content for each Measure and CQM.  We also think it important to tie each report to the specific Regulations, your interpretations, and your processes that exist during that reporting period (based on Federal Register, FAQ and Audit Report data).
9. Deploy online, self-directed e-Learning material - configured to the needs of different clinical, executive and operational teams.  In-person training session might get to most of your team, but given the nuances and complexity of Meaningful Use, some members will benefit from the ability to review the content multiple times, and even to use a quiz to reflect upon the material and solidify their knowledge.  Of course, online e-learning also gives people the ability to study at their own time and pace.  And most Learning Management Systems give you the ability to track education progress at whatever level you deem appropriate.    
10. Staff a Knowledge Center – Dedicate at least one primary contact, deeply knowledgeable in all of meaningful use as the central resource for answering questions, researching the regulations, and resolving  ambiguities in the regulations, or your EHR.  It’s probably a good idea to have a fallback person in the event your primary contact becomes unavailable.  Knowledge Center resources are a great supplement to your on-line e-Learning material as well. 

Becoming compliant with complex regulations in an organization the size of even a small hospital, or medium-sized ambulatory group requires formal capabilities in research, analysis, communication and measurement.  Using a well-structured toolset will enhance these disciplines in nearly every case.  Of course, we would love to sell our solution that contains all these capabilities to you … but if you decide to build it on your own, this design concept should give you a good kick start.  Best of Luck!

 

CMS is Developing an Audit Strategy … Shouldn’t You?

“Congress for the HITECH Act specifically authorized submission of information as to meaningful use through attestation.  CMS is developing an audit strategy to ameliorate and address the risk of fraud and abuse.”  Federal Register, July 2010

 

So how should we be preparing ourselves? 

 

Providers need their own strategies. We suggest patient-level detail reporting.

Bottom line is, no one yet knows the answer to how audits will be conducted. Attestation is deceptively simple,  it requires little documentation, and is complete when you submit your online application. Where we see documentation becoming important is as a response to downstream audits. Here’s what we believe to be a conservative approach to preparing an advance defense.  We see three grades of conservatism in your documentation approach, and a series of additional strategies to add a little additional strength. 

1. Rely on Certified Software to report correct data at the time of an audit –While this has the merit of little or no up-front work, we steer people away from this “wait and see” approach. Audits can happen up to six years later, and a lot can change over six years in a hospital EHR, or in the composition of the team who remembers the details surrounding interpretations of measures in the “grey area” where CMS could not fully predict all the nuances of clinical operations that you have to follow.   
2. Save copies Certified (Summary level) EHR Reports – some CMS advisories have implied that data in a Certified EHR will be deemed accurate. Most reports we’ve seen from Certified EHR’s are a single page per MU Measure. Content is numerator, denominator, percentage, and date range, for the organization and the Measure.  Saving copies of these reports will certainly give you some audit defense. 
3. Create copies of Patient Level Detail – CMS states no explicit requirement for patient level detail, nor is it required for software to be certified. We recommend it though.  CMS requires you to attest to the “accuracy and completeness” of your data, and each Measure. It seems that you cannot do so, without analyzing patient level detail (i.e., would your CFO accept a bank statement with no more detail than just the balance?). Further, some Measures are based on site-specific variables, such as “observation services” vs “all ED patients” choices.  And patient-level detail will show whether all choices have been correctly represented.  The downside is that you may need to create these reports, if you software has only fulfilled the bare bones requirement of certification. 

Regardless of documentation strategy, here are  techniques to enhance the reliability of your defense against an audit:

• Conduct Explicit Reasonableness Checks – If you know your annual volume is 20,000 patients, and your CPOE report is only reporting on 7,000, maybe you should dig a bit deeper into that report.  If your EHR is showing the same patient volume for metrics requiring “all patients” as for “EHR only” patients, then you should be prepared to show data as to why this should be so.  A skeptical auditor will probably estimate your patient volume from billing or census data, and compare that to your EHR records. 
• Maintain a Measures Checklist - In MUM, we show audit checklist reports summarizing all Measures. The checklist identifies the numerator / denominator and date range values, resulting percentage, (or Yes/No value as appropriate), and show whether a link exists to a PDF of an “audit proof” report. Prior to attestation, internal audit should review this checklist, verify each audit proof report, and make sure it shows the level of detail and proof you deem appropriate. We suggest presenting that signed checklist to the CFO (or other attesting officer), prior to attestation. In our checklist we have placeholders for certification “proof” as well. (i.e., a letter from your vendor, certifying that you have purchased from them all modules included in their certified software).
• PDF your reports – and store them in a dedicated, secure repository, with an explicit retention period of at least equal to the six years.  Tie each PDF to your Measures checklist, too. 
• Supplement Screen Prints – as be part of the documentation for those Measures with yes / no Attestation types (like those requiring you to show that a feature in your EHR is “turned on”).  But even with screen prints, we advise showing supplemental reports with patient level detail, showing that the functionality was in place throughout the reporting period. 
• Document Test results – for Measures requiring you to conduct a test of a given capability, store your test data, scripts, and the entities with which tests have been conducted.  Testing plans and associated results should be a part of your six-year Meaningful Use documentation repository. 
• Document your assumptions – the wording around some Measures leaves room for different interpretations of what specific clinical behaviors would be compliant.  Over time, these “grey areas” may be crystallized by CMS pronouncements.  Until that happens, we recommend that your documentation repository leave room for written interpretations, workflows or policies, associated with each individual measure. 

So ultimately, think like an auditor.  Auditors are trained to “professional skepticism”, and are motivated by finding shortfalls.  They will have work plans based on knowing where and how to look for discrepancies, whether you intended them or not.  Defending against their pre-planned approach should not wait until they ring your doorbell, but a well-constructed documentation defense should be done before attesting.  After all, CMS is developing an audit strategy … shouldn’t you?

Where Certified EHR Reporting Falls Short

We all know that to be Certified, EHR vendors must provide reporting against Meaningful Use  Measures,   based on the Objective and Threshold specified in the Regulations. But when an ATCB tests for Certification, EHR vendors only need to show that they can calculate and display the numerator and denominator, and the date range against which these metrics are calculated.

In at least three areas, vendors must address additional capabilities ... or Hospital and Physician Information Technology staff will need to take up the slack.

Configuring Populations

CMS issues clarifications or elaborations via FAQ's regularly.  And sometimes, in the text of the Federal Register itself are nuances that need to get into your reports.  For example, most reports probably already exclude newborns from the calculation of Measures.  But in order to be sure, you should probably take a look at patient level detail. Similarly, under CPOE, CMS issued a series of FAQ's in November of 2010. These FAQ's defined guidelines on who would be permitted to actually enter the order, and represented clarifications beyond what existed in the Final Rule issued the prior July.  In this case, it seems prudent to validate whether your Certified EHR vendor reporting includes all CPOE orders, or filters based on the licensing status of the individual inputting medications.  There is a risk of "false positive" measurement here, depending on the interpretation position you care to defend, and your medication order clinical policies. And of course, each hospital (not relevant to EP's) must choose whether to include all ED patients in each measure, or Observation Services Patients only.  After that choice, check your MU reporting to make sure it is consistent with your choice. 

Patient-Level Detail

If your personal checking account statement only listed an account balance, might you want to see transactions validating it?  Same story with Meaningful Use.  Certification does not test for all the "transactions" making up the numerator and denominator of each measure.  Some ATCB testers will ask a vendor to change an underlying patient record, to see if the measure re-calculates, but the NIST testing procedures do not require an ATCB to verify that the measure is correct, based on all patients in the database.  Do you really care, since you have Certified Technology?

We think so.  On the CMS Attestation site, your CFO (or who ever is attesting to your Meaningful Use) is required to attest to the "Completeness and Accuracy" of all information.  One (likely) interpretation of this statement is that responding to an auditor with "it must be complete and accurate because the EHR is certified" ... might not be good enough. 

Yes / No Attestations

Some Measures require only a Yes / No Attestation (e.g., Clinical Decision Support Rule, or Generating Lists of Patients by Specific Conditions).  Certainly you will know if you have one turned on.  And you'll be sure to count something other than CPOE, right?  But a skittish Compliance Officer, or CFO might want to see the proof you'll show to an auditor.  Might be a good idea to have some supplimental reporting in your hip pocket on each of these. 

Is Your Security Management Process Comprehensive Enough for ARRA?

ARRA HITECH invokes the HIPAA Administrative Simplification Regulation 45 CFR Part 164.308(a)(1) as a requirement for protecting patient information.  Under this act, each covered entity must implement a security management process that includes policies and procedures to prevent, detect, contain, and correct security violations.  Specifically, the regulation stipulates that there must be a risk analysis, a risk management program, a sanction policy, and an information system activity review.  So how do you know that you are on the right track with your organization’s security management process?  There is some high level guidance in the regulation itself, but it generally does not provide the level of implementation assistance that would provide practical advice.  So for each of the areas of 164.308(a)(1), we have identified examples of what a risk assessor would be looking for to validate the appropriate level of compliance.  

(A) Risk Analysis:  A structured and formal review of IT security that includes IT security policies, physical security of data center, infrastructure security, application security, personal computing device security, portable device security, electronic transmission of data/PHI, disaster recovery planning, asset management, and vendor management.

(B) Risk Management Program:  A formal program, strategy, or plan to guide IT security activities that identifies risks and vulnerabilities, along with respective remediation plans.

(C) Sanction Policy:  A formal written policy regarding misuse of PHI, and the consequences of violations, which could include termination.

(D) Information System Activity Review:   Provide documented processes or procedures, along with evidence of the organization’s capability to examine audit logs or system usage databases that are detailed enough to know what level of system access a particular person has, and what data this person has accessed in a time range.

 If your organization can provide evidence of the use of best practices that address each of these major areas of focus, you should be compliant with the regulation. And now with ARRA HITECH, there is actually money at stake.   

Scott Owens, PMP, CBCP, HITRUST Practitioner,  is the Managing Director with BluTinuity LLC, a risk management focused consulting firm, and a guest blogger for Everything HITECH.  For more information, please see http://blutinuity.com. 

Show me the Hidden Requirements in Meaningful Use!

Read the list of ARRA HITECH Requirements. You can find them most anywhere these days. And on the surface, they don’t look all that hard. In many cases, what you see is what you get … they are fairly straight forward. And we have good vendor software, certified to do all we ask of it.

But as we’ve worked with MUM Subscribers, we’ve uncovered some cases where extra work pops up … beyond what might be obvious. The last thing any of us want, is to get well into our reporting period, and find that we are not compliant because of some tiny oversight. So we thought that in this article, we would share a couple we’ve seen, and maybe some other folks will chime in with observations of their own.

1. Provide patients with an electronic copy of their health information upon request

Clear part: How hard can it be? Our EHR can do this several ways. We can e-mail a PDF, give a CD, populate Microsoft Health Vault, or give patients access to their own chart online.   Hidden Part: In order to measure compliance, someone has to log the fact that a patient asked for electronic data. Every time they do it. And then, someone needs to log whether we actually provided the data electronically.

 

2. Record and chart changes in vital signs

Clear part: Height, weight and blood pressure. Simple and clinically sound.   Hidden Part: In one of our subscriber ED’s, we found that height and weight didn’t often get tracked for patients with trauma, or true medical emergencies. In another case, a group of EP’s found that they typically don’t track blood pressure until age 3 … but the regulations state this needs doing for all patients age 2 and over.

 

3. Use CPOE for medication orders

Clear part: Everybody’s favorite. 30% of Medication orders must be done via CPOE. Easy to measure.   Hidden Part: CMS requires that the order must be physically entered by a licensed healthcare professional capable of reacting to any real-time alerts and modifying the order as a result. So your pharmacist, unit clerk or even nursing staff probably does not qualify. Gotta be the doc.

 

4. Record demographics

Clear part: I must be kidding, right? Date of birth, gender, preferred language and ethnicity. Simple registration system stuff. Oh … one more thing. Preliminary cause of death in the case of inpatient mortality.   Hidden Part: We found two hidden elements here. One, these data are not always transferred to the EHR from admissions or registration systems. And of course, if it is not in the EHR, it does not count. We also found that in the case of death, hospitalists in a couple of our hospitals simply recorded a code of “expired”. And cause of death often gets measured outside the hospital and never makes it to the chart. Watch your clinical practices here!

 

5. Use certified EHR technology to identify patient-specific education resources and provide those to the patient

Clear part: We do this all day long every day. Our library system for patient education is constantly up to date and discharge staff draws on it for every patient.   Hidden Part: Two hidden gems again. First, the EHR must be aware of the specific education content available. In a lot of our hospitals, this is done electronically, but in stand-alone systems not part of the EHR. When we get Certified EHR technology in place, now we are in the position of populating our EHR (or EHRs) with a list of educational content available, duplicating existing systems … or integrating the library and getting it certified. Ouch. Self Certification.   Second, is the tracking problem. Again. Someone has to log all the cases where patient-specific education materials were provider from EHR content.

 

6. Quality Reporting

Clear part: Certified EHR software does quality reporting, no problem.   Hidden Part: Not all the data to generate these reports always gets into the EHR. Several reports require time and date medications were administered to patients, compared against time and date of procedures, admission or discharge. The hidden requirement here may be electronic Medication Administration capabilities, since manual medication administration data into the EHR as a matter of course may be too much work.   VTE reporting sometimes requires the reason a medication was not administered, which may not make it into your EHR on a regular basis.

 

So, this is half dozen places with hidden requirements. We’re aware of a couple others, and there are certainly some we don’t yet track. Watch for an upcoming article on “Why your Certified Software Might not be as Certified as you thought”, for an example of another hidden requirement. This highlights the importance of having someone on staff with deep knowledge of all of ARRA, keeping an eye on the ball.

 

Let us know what else you see!

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

 

 

What is a Licensed Healthcare Professional (for CPOE!)

The final rule states that any licensed professional can qualify for CPOE order entry.  However, there is little guidance as to definition of “licensed professional”.  In our research we found two relevant citations, as follows:

Use CPOE for orders (any type) directly entered by the authorizing provider (for example, MD, DO, RN, PA, NP).

Page 73, Final Rule Draft

We agree with those commenters who recommend allowing any licensed healthcare professional to enter orders using CPOE.  We further refine this recommendation to be that any licensed healthcare professional can enter orders into the medical record per state, local and professional guidelines. 

Page 75, Final Rule Draft

So it appears that MD, DO, RN, PA and NP are valid, as well as any others defined per state, local or professional guidelines, although the regulation is somewhat silent on what specific guidelines may be applicable. 

A further clarification can be found in a FAQ on the CMS website, stating that the individual qualifying for CPOE must be able to exercise clinical judgement, and make a decision before the order is executed.  According to one of our hospital colleagues, this will probably take pharmacists out of play in qualifying as CPOE orderers (for Stimulus purposes, anyway).  Here's the CMS link: https://questions.cms.hhs.gov/app/answers/detail/a_id/10134/~/%5Behr-incentive-program%5D-who-can-enter-medication-orders-in-order-to-meet-the

Make sure your EHR's detail "audit proof" reporting includes an identification of who entered the order! 

How Should Newborns be included in Inpatient Counts for Meaningful Use Measures?

Including or excluding newborn infants in generalized numerator and denominator statistics could make a difference between pass and fail  in some requirements for many hospitals.  The Final Rule addresses this, by generally excluding newborns from such counts.  Be sure and adjust your reporting metrics based on excluding newborns!  The one exception appears to be that newborns should be included in ICU counts, in denominator and where appropriate, in numerator calculations. 

 In excluding nursery days from the count of Medicare inpatient bed days, we are following the precedent of not counting such days for purposes of the direct medical education, indirect medical education, and disproportionate share adjustments under the Medicare IPPS.  As in the case of the term "subsection (d)" hospital, we believe that, in the absence of clear direction from the statute to the contrary, the most appropriate policy is to interpret terms such as "inpatient bed-days" in the light of existing Medicare program policies and precedents. 

 

Under our policies for the direct medical education, indirect medical education and disproportionate share adjustments, a bed must be permanently maintained for lodging inpatients in order to be included in available inpatient bed and inpatient bed day counts.  We exclude the days provided to newborns (except for those in intensive care units of the hospital) because healthy new born infants are not provided with an acute level of hospital care.  (This is not the case with newborns assigned to intensive care units, who are included in the counts for those units.) For these reasons, nursery days are explicitly excluded from:

 

• The counts of Medicare inpatient hospital days and total inpatient hospital days for purposes of direct graduate medical education payments under section 413.75(b) of the regulations, where the definition of Medicare patient load reads: "inpatient days in any distinct part of the hospital are included and nursery days are excluded."
• The counts of bed days for purposes of the Medicare indirect graduate medical education adjustment under section 412.105(b): the "count of available bed days excludes bed days associated with… (5) Beds or bassinets in the healthy newborn nursery…."
• The count of beds for purposes of the Medicare DSH adjustment under section412.106(a)(i) of the regulations: "The number of beds in a hospital is determined in accordance with §412.105(b)."

We note that, in addition to excluding nursery days from the numerator of the Medicare share fraction, these days are excluded for the same reasons from the count of total inpatient bed days in the denominator of the Medicare share fraction.  We therefore do not believe that excluding these days would result in disadvantage to hospitals in determining their Medicare share fractions for purposes of calculating EHR incentive payments. 

 Page 411, Final Rule Draft

HITECH will keep your Business Intelligence Team Busy

 

One of our Meaningful Use Monitoring (MUM) customers recently commented on the significant amount of work his hospitals will have to do to develop proof of compliance for the HITECH requirements. Much, but not all, of the reporting work may be supported by EHR vendors – however, many hospitals have multiple EHR vendors (especially true with ED and OR) that will require coordination and synchronization.  A large hospital will have to access and organize scores, or even hundreds of reports to analyze and prove Meaningful Use.  These hospitals will have to build reporting across multiple systems (EHRs, ADT, Pharmacy, Registries, Lab, and Radiology).  There is probably no way around this.  Here are a couple examples of this complexity:

  

 

• Determine, for each Quality Report, that all data elements exist in your (relevant) EHR, to support creation of the report (even if it is not necessary to create the report from the EHR in year 1 for Stage 1 requirements, you must attest to the fact that you could have);
• Incorporate clinical lab test results into EHR as structured data – seems straight forward until you realize the need to gather all lab tests ordered (manual, other systems), not just the ones ordered from  your primary EHR system. Then you need to ensure the results are in a positive / negative or numerical format to be countered toward the 50% measure threshold.
• Analyze all "transitions of care", and report on whether a "medication reconciliation" took place;
• Identify, for all unique patients (whether they are in the EHR or not), whether they had problem list coded via ICD-9 or  SNOMED (in the EHR);
• Log each instance of transition of care (between providers), and identify whether a Summary of Care record existed, and was provided (from the EHR).

OK, you get the point.  There are currently 14 Meaningful Use Requirements for hospitals, and 15 Quality Reports.  If you have one EHR only, and you can guarantee that all relevant data is in the EHR, then you will not need to integrate with other hospital systems.  Most of us are not in that position, yet.  The complexity of many hospitals will require that in order to conduct the analysis, department-level reporting will be needed.  And you'll need to create these reports early on, so you can run them regularly, in order to monitor your progress towards compliance. 

Hospitals will need tools and processes to organize and report status against all that work, and a simplified organization and reporting scheme will save a lot of effort on the part of clinical evaluators, Business Intelligence Teams, and internal audit.  One design concept we have adopted, is to create a link within MUM at the level of department and requirement, by which users can identify (and even execute) each unique report that analyzes and proves departmental compliance, for each requirement.  This is a powerful concept!  We also provide the audit proof link, by which these reports are organized along requirement and departmental lines. 

  

 

So ... it seems prudent to get your BI Team involved early in the process!  Educate them in each single requirement, so that they can start the process of evaluating how to track progress, and log proof. It will be useful to your clinical leadership to provide data that shows HITECH compliance status.  Anecdotal attestations as to compliance might be useful to determine whether to pursue meaningful use, but won't stand up to CMS audit. 

 

Jay Fisher | @JayRFisher