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. 

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?

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. 

Must "Interoperability" be "Interactive" to qualify for Meaningful Use?

Meaningful Use Requirements exist for three or four specific interoperability topics, depending on whether you are a hospital or ambulatory practice. One good question we discuss regularly is around the concept of how "interactive" must these items be. ONC provided a response to one specific requirement (Submission to Immunization Registries), stating that batch transmission would qualify a provider:

The certification criterion at 45 CFR 302(k) does not specify, and is not intended to specify, when submissions should be made or the periodicity of the submissions. Consequently, submitting batch files to an immunization registry, provided that they are formatted according to one or both of the adopted standards, is not prohibited by this certification criterion and would be acceptable. (ONC FAQ 9-10-002-1)

Absent any specific quotations to the contrary, we're relying on this as directionally valid for other interoperability requirements, where appropriate (electronic syndromic surveillance, reportable lab results, capability to exchange key clinical information).  Seems reasonable, doesn't it?

Jay Fisher | @JayRFisher

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!

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

Medicare Advantage "Informational Only Claims" May benefit your HITECH Case

PPS hospitals have been instructed for the last several years to submit informational only claims to the Medicare program.  Informational only claims (shadow billing) are billed for patients enrolled in a Medicare Advantage Plan and include:

 

• Covered 11X type of bill
• Condition code 04
• Beneficiary’s medicare HICN
• All other required claim elements

 

Effective October 1, 2010, critical access hospitals should submit informational only claims.  The reason that you may want to do so is because the number of Medicare C days billed will go into the calculation of your payment to be received as a meaningful user of certified electronic health records.  If you have not submitted the informational only claims to the Medicare program, you will not be able to use the related Medicare C days in your calculation of reimbursement for electronic medical records.  The information for these claims will print out on a separate PS&R report page and included on the cost report in 2011.

 

If you opt to skip submitting the informational only claims, please be aware that you may receive less than originally anticipated when requesting payment from the government as a meaningful user of certified electronic health records. 

For further information, contact:

Donna Nelson, CPA  |  Manager  |Wipfli  | 715.858.6663  |  DNelson@WIPFLI.com

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

Looking for Requirement Detail? Try MUMrequirements.com !

We are excited to promote stimulating conversation at the heart of Meaningful Use, with our new informative site at MUMrequirements.com  

This new site lists each individual EHR usage requirement from the Federal Register, with the comment and response background consolidated, useful interpretations, and an ability to share your thoughts with other professionals via standard blogging tools. 

You can filter on the requirements for hospitals, or EP's, and menu vs core.  What's more, you can use simple search tools to hunt out all the requirments containing a common concept (like "structured data" or "emergency department"). 

Join in the conversation!

Navigating the Final Rule for Clinical Quality Measures for EP's

We recently had a question on where to find information on Clinical Quality Measures for EP's, so I did  a little digging around. 

First, you should review the portion of the Final Rule that lists the Measures and which are required for each specialty.  The Final Rule document is available from CMS on this web page:

http://healthit.hhs.gov/portal/server.pt?open=512&objID=2996&mode=2

On the right-hand panel, upper corner will be a link to the PDF containing the Final Rule document.  Within the Final Rule Document, there is a general discussion of Clinical Quality Measures starting on page 44380, but the list of specific measures, and which are required under which circumstances, is on pages 44398-44408.  Of course, this section does not give you much insight into the detail specifications of each report, but there is a pretty good PDF on the CMS site containing the specifications for each quality measure.  The Site URL is:

http://www.cms.gov/QualityMeasures/03_ElectronicSpecifications.asp 

Near the bottom of the resulting page is a section for Downloads.  In that section is a PDF titled "EP Measure Specifications".  That document contains the calculations and data fields for each Quality Measure. 

We think it is prudent for each provider to create a matrix, listing for each relevant quality measure, the required data elements, and mapping those elements to their EHR(s), and further determining that the  relevant data elements are being populated by your clinicians sufficiently to meet the data gathering requirements.  Big job!

Jay Fisher

MeaningfulUseMonitor.com

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

 

 

 

 

Check out our HITECH Hero Series for Summary Concepts

In the Regulatory Quiet Period over the past couple months, we've created a series of vignettes, which illustrate concepts within ARRA HITECH's Meaningful Use regulations that you might enjoy ...

CMS will publish, on their website, all hospitals who are Meaningful Users.  Are there any implications of being on or off that list?

 

What's the difference between having EHR Software, and achieving Meaningful Use? 

 Who has to be involved in your hospital's Meaningful Use efforts?

All we have to do is submit an Attestation to CMS, Right?

 

 

What integration might be required to make Meaningful Use work?

Ok, so these are a bit frivolous, but maybe they help think through a point or two.  Hope you enjoyed!

Jay Fisher | @JayRFisher 

Privacy and Security Revisited

Over the past couple weeks, we’ve been head-scratching over one of the HITECH Requirements, related to Privacy and Security.  Here’s the language from the Federal Register:

“Conduct or review a security risk analysis per 45 CFR 164.308 (a)(1) and implement security updates as necessary.”

 

  

So, here’s the question.  Is this a slam-dunk (all you have to do is conduct an assessment), or an impossibility (implement security updates as necessary)?  Thanks mainly to Kirsten Wilde, an independent HIPAA Security Consultant, and Nancy Davis of Ministry Healthcare in Wisconsin, we’ve come to a simplified conclusion.  I don’t suppose our conclusion is definitive in the eyes of CMS, but bears the value of some practical experience of these professionals, as well as a handful of others.  In fact, we've had a panel of experts from hospital, consulting and software vendor firms that really helped make sure we covered the bases.  Just to provide a sense of the different perspectives we've incorporated, major contributors to this included Penny Zeller, of New West Consulting, Phil Deleel of Claxton-Hepburn Medical Center, Colin Fletcher from Sun Microsystems. 

  

 

First of all, everyone knows that this is not a new requirement, right?  It has been around for quite a while.  Our first research path was to the 45 CFR 164.308 (a)(1) referenced in the HITECH rule.  That was disappointing.  After reading half a dozen pages, we came down to a paragraph, which really pointed to the details of a “security risk assessment”.  What we found, was that the answers are not actually in the CFR manual, but are referred out to a NIST document.  Here we struck gold!  The NICS material is concise, definitive and easy to follow.  Details of the security risk assessment can be found at:

http://csrc.nist.gov/publications/nistpubs/800-66-Rev1/SP-800-66-Revision1.pdf 

  

See pages 17-19 of the actual document (pages 25-27 of the PDF) and appendix E.   Following this, you can clearly figure out a reasonable work plan for conducting the assessment.  Ok, having conducted this type of assessment, what do you do with the results?  Most hospitals have an approach already, and very few have been audited. 

  

 The notable “first” was in March of 2007, when Atlanta's Piedmont Hospital became the first institution in the country to be audited for compliance with the security rules of the Health Insurance Portability and Accountability Act (HIPAA).  Just Google “Piedmont” and “HIPAA” and in 10 minutes you’ll understand that history pretty well.  As a result, CMS / OCR (Office of Civil Rights) developed a list of 42 questions that consultants have been using ever since.

  

After reviewing these questions, following up with some internet searches, and discussions with Nancy, Kirsten and our other HITECH Advisory Panel members, we came away with a couple observations related to what is prudent to do with the results of a risk assessment:

  

1.   Absolute Security Compliance is not a reasonable standard.  Probably, no organization can ever achieve it, because of human factors and the potential for simple operational errors.

2.   Providers need to show diligence.  Strong evidence of diligence might be having a committee of senior level staff meeting regularly to discuss their activities related to open items identified as a part of the risk assessment.  Stronger yet, would be to have an individual dedicated to this task (rather than part of a job description covered under “other duties as assigned”).  Here’s the results of what we have posted to our subscribers:
 

ADVISORY PANEL INTERPRETATION

Lower risk Interpretation:   Security risk assessment has been completed. Plan for addressing identified gaps is regularly (e.g. quarterly) updated based upon results of updated security risk assessment. Mitigation of gaps is an active process. Security risk management activities are documented. Attestation is required for Stage 1 at least once prior to the end of the reporting period. Low risk recommendation to complete test again.

  

Higher risk Interpretation: Security risk assessment has been completed. Plan for addressing identified gaps is developed once based upon results of security risk assessment. Implementation of security updates  has begun.

  

TECHNOLOGY

Third-party software likely to be required to assist with the security risk assessment.

POLICY/PROCEDURE

Policy / Procedures define contents of security analysis to include: risk assessment methodology, risk management, security and sanction policy and information review. Policy / Procedure provides audit trail on a regular basis.

  

COMPLIANCE REVIEW DOCUMENTATION

Risk analysis and risk management policy and procedures, audit trail, gap analysis, security risk test results and additional documentation.  

Green:

Fully compliant with current risk assessment review completed, risk management procedures completely documented and any identified security gaps have been resolved or are being actively worked.

Yellow:

Risk assessment review conducted/current and Technical components to support HIPAA security rule are in place however, not all risk management procedures are documented, or gaps in security processes have not all been addressed and are not being actively worked.

Red:

Either risk assessment review not current or technology gaps have not been addressed

  

What do you think?  Are we on target?

Jay Fisher | @JayRFisher

ARRA Meaningful Use Guidelines as an Implementation Planning Aid

ARRA HITECH represents important financial and regulatory compliance content for most hospitals and medical groups for the next several years.  But we believe that Meaningful Use, Quality Measure Management, and EHR Interoperability guidelines established by CMS also represent a body of work in defining reasonable goals for most EHR Implementations – quite apart from the regulatory implications. 

For hospitals embarking on new EHR journeys, or re-evaluating their EHR priorities, one of the most difficult and time-consuming tasks is to define operational and clinical EHR goals that are easily communicated to medical staff, and where progress can be easily measured.  In some cases, your vision becomes a competitive physician recruitment and retention weapon, showing that you are a state-of-the-art Medical Facility.  We have observed cases where developing this vision takes months.  Getting the message to all relevant stakeholders, and getting obtaining commitment is time consuming and critical to successful implementations.  Clinician buy-in may be the single most important factor in determining the timing, and cost of getting your EHR up and running. 

Adopting the CMS HITECH requirements, as the starting point for a clear, relevant set of goals makes a lot of sense.  Your institution may choose to go farther than these requirements suggest, or you may choose to phase them in over multiple future periods.  HITECH cuts through the amount of time it takes to get organized, develop a clear and convincing vision, communicate expectations and progress, and keeps your entire organization clearly focused on your EHR goals … and does so over the life of your programs. 

I've always been a Project Manager and Program Manager.  My principal tracking and communication tools have been workplans in Microsoft Project, or Open Workbench, or something similar.  And, while I loved the order and predictability these  plans give, we were always missing something.  That missing element was an ability for the business (or clincial) stakeholders to clearly evaluate and communicate their progress. 

The ARRA Meaningful Use (well, 23 Meaningful Use requirements and another 40 or so Quality Measures) define one possible vision that has value beyond merely getting money from CMS.  If we can figure out good ways to communicate those standards across all our clinicians, and communicate our progress against them, the government may have done us all a favor!   Take a look at a tool we have developed for our clients' use.  It organizes and interprets the requirements in a way to drastically improve communication.  It gives clinical departments a simple, ongoing way to show their progress.  From a project management point of view, you should really consider using the HITECH requirements to measure accomplishments in a  way that makes sense to your business and clinicians ... not just to your project managers. 

Jay Fisher | @JayRFisher

Our Pharmacy System does drug-drug, drug-allergy and drug-formulary checks. Are we covered?

The Federal Register never quite comes out to say yes or no explicitly to this question.  However, the context of the discussion on the requirements to conduct these checks certainly implies quite strongly that whether or not it exists in your Pharmacy, the EHR also needs to conduct real-time checks, assumably at order entry time.  Consider the following text from page 1860:

The capability of conducting automated drug-drug, drug-allergy, and drug-formulary checks is included in the certification criteria for certified EHR technology (to be determined by ONC in its upcoming interim final rule). This automated check provides information to advise the EP or eligible hospital’s decisions in prescribing drugs to a patient. The only action taken by the EP or eligible hospital is to consider this information. Many current EHR technologies have the option to disable these checks and the certification process does not require the removal of this option. Therefore, in order to meet this objective, an EP or eligible hospital would be required to enable this functionality. While this does not ensure that an EP or an eligible hospital is considering the information provided, it does ensure that the information is available.

It rather makes sense this way, if you consider the direction of EHR Meaningful Use to facilitate clinical decision support.

Jay Fisher | @JayRFisher

For Physicians ... must all locations be automated to qualify for incentives?

We received a question recently regarding physician practices, and how to count “denominator” portions of several measures, such as CPOE.  The situation we covered was that of a given physician seeing patients in multiple locations, where not all locations are yet “up and running” on EHR.  On page 1859 of the Federal Register we found language that gives these providers the benefit of being  able to count only the patients seen in the “automated” location:

We are concerned about the application of this denominator for EPs who see patients in multiple practices or multiple locations. If an EP does not have certified EHR technology available at each location/practice where they see patients it could become impossible to reach the thresholds set for measuring the objectives. We do not seek to exclude EPs who meaningfully use certified EHR technology when it is available because they also provide care in another practice where certified EHR technology is not available. Therefore we are proposing all measures be limited to actions taken at practices/ locations equipped with certified EHR technology. A practice is equipped if certified EHR technology is available at the beginning of the EHR reporting period for a given location.

Of course, for multi-location physicians, there need to be some guidelines on which locations are “relevant”.  It seems that seeing only a small percentage of patients does not help … the doctor must have half or more of his patients seen at an EHR enabled location (also page 1859):

We believe that an EP would have the greatest control of whether certified EHR technology is available in the practice in which they see the greatest proportion of their patients. We are proposing that to be a meaningful EHR user an EP must have 50 percent or more of their patient encounters during the EHR reporting period at a practice/location or practices/locations equipped with certified EHR technology. An EP for who does not conduct 50 percent of their patient encounters in any one practice/location would have to meet the 50 percent threshold through a combination of practices/locations. While control is less assured in this situation, CMS still needs to advance the health care priorities of the definition of meaningful use and provide some level of equity.

So it seems necessary to keep track of patient volume by location, for all your  physicians to be able to qualify …

Jay Fisher | @JayRFisher

Measuring ED Throughput Might be Hard for Measuring Meaningful Use

When we first started reading about Quality Reporting, our first thought was, why bother making this a HITECH Requirement?  Most of us do it already, right?  Then came the observation that all the requisite data needed to be part of a Certified EHR.  Then we started looking at some of the data.  Here's one interesting item.  Quality Report

 "ED-2NQF 0497: Emergency Department Throughput – admitted patients.  Admission decision time to ED departure time for admitted patients"

This item has at least one tricky element.  The admission decision is made by someone outside the ED!  This means that the time of the decision is not likely to reside in the ED's EHR (unless, of course, the hospital has one common EHR that includes ED). 

Jay Fisher | @JayRFisher

Do Multi-EHR Hospitals fulfil Meaningful Use Compliance more Easily?

As we review requirements, we find that for hospitals with multiple EHR systems in place, compliance changes, just a little. Click on the image to the left, here for a thoughtful, simplified illustration.  And have a little fun.

Seriously, though ... it seems that for Quality Reporting (if not many Meaningful Use Requirements) that multiple departmental EHR's might be involved in gathering the data for an individual requirement.    HITECH requires this data be drawn from your Certified EHR's.  Consider, for example the need to calculate an all-hospital 30 day re-admission rate.  Or (a possible scenario) you have an EHR in your OR that is not Certified, but have a general acute care EHR product which is Certified.  You might need to move data to qualify.  And to satisfy the need to do drug-drug or drug-allergy checks, you'll probably need to do it in each place in your clinical environment ... regardless of what vendor's product is being used. 

Bottom line - we think you've got to inventory all your EHR assets, and plan accordingly.

Jay Fisher | @JayRFisher

PHR, Portal, Patient Web ... What does HITECH Require?

I'll bet most of our hospital and physician clients are hearing a lot these days from vendors promising to make them HITECH Compliant.  And among those vendors will inevitably be purveyors of portal software, Electronic Personal Health Records and a whole raft of consultants promising to deliver Patient interaction nirvana.  Many EHR vendors have portals attached to their products, allowing patients access to their health record data in your hospital.  It might be useful to study the Proposed Rule’s language on PHR and Portal, and other Web Stuff. 

So, here we go … hospitals have two specific requirements. 

Requirement 1:

Hospitals must provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, allergies, discharge summary, procedures), upon request.  The relevant measurement specifies that at least 80% of all patients who request an electronic copy of their health information must be provided it within 48 hours.

 

Requirement 2:

Hospitals must provide patients with an electronic copy of their discharge instructions and procedures at time of discharge, upon request, for at least 80% of all patients who request an electronic copy of their discharge instructions and procedures are provided it.

 

In both cases, the ruling identifies that electronic copies may be provided through a number of secure electronic methods (for example, personal health record (PHR), patient portal, CD, USB drive).  Relative to the format and content of these requirements, the Proposed Rule is generally silent.  (For a useful background on PHR, click here). 

 

Under a different topic, “Capability to exchange key clinical information”, the Proposed Rule provides and example of using a personal health record as a vehicle by which a patient could authorize a third party (i.e., insurance company) access to their data.  In that context the regulation provides for structured electronic format, or free text or scanned image when structured data is not available. 

Bottom line … this should be a fairly easy requirement from a technology standpoint, but with some interesting operational implications, standards definition, and a healthy dose of privacy and security guidelines. 

 

Jay Fisher | @JayRFisher

Because of Quality Reporting, you may need eMAR to Qualify for Meaningful Use

In one of our Advisory Panel discussions recently, we uncovered a need that may be quite advanced for Stage 1 hospitals.  Consider the following text from Quality Measure NQF 0374 on Page 1897 of the Federal Register:

"This measure assesses the number of patients diagnosed with confirmed VTE who received intravenous (IV) UFH therapy dosages AND had their platelet counts monitored using defined parameters such as a nomogram or protocol."

Since  each data element for your quality reports needs to reside in your EHR (The Two-Headed Beast of Quality Reporting), the above referenced quality report would need to store data on patients who "received intravenous UFH therapy dosages".   Once we state a need to track patients who received medications, we move from the realm of Order Entry, to Medication Administration.  Regardless of whether our EHR has this capability internally, or your hospital uses a separate sytem, you need to get that Medication Administration data into your EHR! 

A similar requirement for Medication Administration data exists in Quality Reports NQF 0437, NQF 0438, NQF 0371, NQF 0372, NQF 0373, NQF 0374, NQF 0376, NQF 0163, NQF 0148, NQF 0528, NQF 0151, NQF 0356, NQF 0527, NQF 0529. 

This is a high bar indeed!  According to the HIMSS EMR Adoption model's 2009 data, only 6.1% of hospitals have reached this far.  Regardless of your EHR Vendor's capabilities, this set of requirements implies implementation of practices (and possibly add-on tools) that will take many hospitals a while to get in place. 

Action Suggested: HHS has invited comment on which of the proposed qualilty measures should be deferred to 2012, and why. We think this set of measures should be deferred, based on HIMSS Adoption Model data, indicating that it is a bar too high in the short term.  If you are considering a filing of comment, perhaps this should be in your report to HHS!

Jay Fisher | @JayRFisher 

 

 

How does Meaningful Use rule define CPOE?

With CPOE as a core (and perhaps difficult) requirement for both hospitals and physicians, some of our discussions have questioned the scope of the term.  Here's the language frompage 49 of the proposed rule (pages 1854 and 1855 in the federal register):

"We propose to define CPOE as entailing the provider's use of computer assistance to directly enter medical orders (for example, medications, consultations with other providers, laboratory services, imaging studies, and other auxiliary services) from a computer or mobile device.  The order is also documented or captured in a digital, strucuted and computable format for use in improving safety and organization.  For Stage 1 criteria, we propose that it willnot include the electonic transmittal of that order to the pharmacy, laboratory, ordiagnostic imaging center."

As to who can enter the order, see our post at http://www.everythinghitech.com/everything-hitech/2010/10/what-is-a-licensed-healthcare-professional-for-cpoe.html 

Any one have other thoughts?

Jay Fisher | @JayRFisher

 

So you need to be “connected” – What is CMS looking for in Stage 1?

One of the four cornerstones of the ARRA HITECH law is connectivity. Along with having a certified (HHS certified to be exact) EHR, using the EHR in a meaningful manner and reporting clinical quality measures, connectivity for the purpose of care coordination rounds out the major criteria to be compliant and, therefore qualify for HITECH stimulus funding. But what’s it mean to be “connected” ? 

Read more of the feature here

 

Chris Coleman | Chris.Coleman@C3Partners.Biz