Skip to content


Stage 1 Meaningful Use

I’d like to continue our discussion of Meaningful Use by looking at some of the timelines and language provided by CMS:

Stage 1 Criteria for Meaningful Use

The proposed Stage 1 criteria for meaningful use focus on electronically capturing health information in a coded format, using that information to track key clinical conditions, communicating that information for care coordination purposes, and initiating the reporting of clinical quality measures and public health information.

The proposed criteria for meaningful use are based on a series of specific objectives, each of which is tied to a proposed measure that all EPs and hospitals must meet in order to demonstrate that they are meaningful users of certified EHR technology.

For Stage 1, which begins in 2011, CMS proposes 25 objectives/measures for EPs (Eligible Providers) and 23 objectives/measures for eligible hospitals that must be met to be deemed a meaningful EHR user.

In 2011, all of the results for all objectives/measures, including clinical quality measures would be reported by EPs and hospitals to CMS, or for Medicaid EPs and hospitals to the states, through attestation.

In 2012, CMS proposes requiring the direct submission of clinical quality measures to CMS (or to the states for Medicaid EPs and hospitals) through certified EHR technology. CMS recognizes that for clinical quality reporting to become routine, the administrative burden of reporting must be reduced. By using certified EHR technology to report information on clinical quality measures electronically to a health information network, a state, CMS, or a registry, the burden on providers that are gathering the data and transmitting them will be greatly reduced. The burden of generating the necessary information for the provider to then use the information to improve health care quality, efficiency, and patient safety will also be reduced.

The key take-home points being:

(And we’ve summarized each of these in previous blog posts).

  • For the first year (2011), CMS will allow reporting by attestation
  • Starting in 2012, reporting will be required to be submitted electronically to CMS

The goals of CMS are:

  1. To have providers using a certified EHR in a meaningful manner (e.g. E-Prescribing).
  2. To use EHR technology so that it provides for the electronic exchange of health information (to improve quality of care).
  3. To be able to submit information on quality and other measures to the government for public health purposes.

Posted in ARRA, EMR, Implementation.

Tagged with , , , .


Meaningful Use: Summary for Hospitals

Today we’ll have a continuation of yesterday’s post (“Meaningful Use: Summary For Providers”) by reviewing the Meaningful Use rules for Hospitals.

And once again, the full 500+ page document is available here:

http://www.federalregister.gov/OFRUpload/OFRData/2009-31217_PI.pdf

Meaningful Use for Hospitals

  1. CPOE is used for at least 10% of all orders
  2. Medication interaction checks (drug-drug, drug-allergy, drug- formulary) functionality must be enabled.
  3. Maintain an up-to-date problem list for 80% of patients admitted
    1. Include current and active diagnoses
    2. Based on ICD-9-CM or SNOMED
  4. Maintain an active medication list for at least 80% of patients admitted.
  5. Maintain an active medication allergy list for at least 80% of patients admitted.
  6. Record demographics information (as structured data) for at least 80% of patients admitted.
  7. Record and chart changes in vital signs for at least 80% of patients admitted age 2 and over.
    1. Blood Pressure
    2. BMI
    3. Growth Chart (for children age 2 to 20)
  8. Record smoking status for at least 80% of patients admitted 13 years old or older.
  9. Incorporate clinical lab-test results into EHR as structured data for at least 50% of all clinical lab results ordered.
  10. Generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research, and outreach (at least one report must be generated listing patients with a specific condition).
  11. Report hospital quality measures to CMS or the States (can be manually submitted in 2011, and must be electronically submitted in 2012).
  12. Implement five clinical decision support rules relevant to specific clinical quality metrics
    1. Must be relevant to specialty or high clinical priority, including ordering of diagnostic tests
    2. Must have the ability to track compliance with these rules
  13. Electronic insurance eligibility checking (from public and private payers) for at least 80% of patients admitted.
  14. Electronic claims submission (to public and private payers) for at least 80% of claims.
  15. Provide patients with an electronic copy of their health information within 48 hours (including diagnostic test results, problem list, medication lists, and allergies) for at least 80% of patients requesting electronic copies.
  16. Provide patients with an electronic copy of their discharge instructions and procedures at the time of discharge, for at least 80% of patients requesting electronic copies.
  17. Demonstrate the capability to electronically exchange clinical information (discharge summary, procedures, problem list, medication list, allergies, diagnostic test results, etc.) by performing at least one test of transmission.
  18. Perform medication reconciliation at relevant encounters and each transition of care for at least 80% of relevant encounters.
  19. Provide a summary care record for each transition of care and referral for at least 80% of transitions and referrals.
  20. Demonstrate the capability to submit electronic data to immunization registries and actual submission where required and accepted, by performing at least one test of transmission to immunization registries.
  21. Demonstrate the capability to provide electronic submission of reportable lab results to public health agencies, and actual submission where it can be received, by performing at least one test of transmission to public health agencies.
  22. Demonstrate the capability to provide electronic syndromic surveillance data to public health agencies and actual transmission according to applicable law and practice, by performing at least one test of transmission to public health agencies.
  23. Protect & ensure the security of electronic health information by implementing appropriate technical capabilities, and conducting a security risk analysis, and implementing security updates as necessary.

Posted in ARRA, EMR, Implementation.

Tagged with , , , .


Meaningful Use: Summary For Providers

On Dec. 30, CMS (the Centers for Medicare and Medicaid Services) issued a proposed definition for the central concept of “meaningful use” of EHR technology.

To be eligible to receive payments under the ARRA incentive programs, healthcare professionals and hospitals must be able to demonstrate meaningful use of a certified EHR system.

The full 500+ page document is available here:

http://www.federalregister.gov/OFRUpload/OFRData/2009-31217_PI.pdf

Here are the key points from that document that establish “Meaningful Use”:

Meaningful Use for Providers

  1. CPOE is used for at least 80% of all orders
  2. Medication interaction checks (drug-drug, drug-allergy, drug- formulary) functionality must be enabled.
  3. Maintain an up-to-date problem list for 80% of patients seen
    1. Include current and active diagnoses
    2. Based on ICD-9-CM or SNOMED
  4. Use e-prescribing (eRx) for at least 75% of prescriptions.
  5. Maintain an active medication list for at least 80% of patients.
  6. Maintain an active medication allergy list for at least 80% of patients.
  7. Record demographics information (as structured data) for at least 80% of patients.
  8. Record and chart changes in vital signs for at least 80% of patients age 2 and over.
    1. Blood Pressure
    2. BMI
    3. Growth Chart (for children age 2 to 20)
  9. Record smoking status for at least 80% of patients 13 years old or older
  10. Incorporate clinical lab-test results into EHR as structured data for at least 50% of all clinical lab results ordered.
  11. Generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research, and outreach (at least one report must be generated listing patients with a specific condition).
  12. Report ambulatory quality measures to CMS or the States (can be manually submitted in 2011, and must be electronically submitted in 2012).
  13. Send patient reminders for preventive/ follow-up care for at least 50% of patients age 50 and over.
  14. Implement five clinical decision support rules relevant to specific clinical quality metrics
    1. Must be relevant to specialty or high clinical priority, including ordering of diagnostic tests
    2. Must have the ability to track compliance with these rules
  15. Electronic insurance eligibility checking (from public and private payers) for at least 80% of patients.
  16. Electronic claims submission (to public and private payers) for at least 80% of claims.
  17. Provide patients with an electronic copy of their health information within 48 hours (including diagnostic test results, problem list, medication lists, and allergies) for at least 80% of patients requesting electronic copies.
  18. Provide patients with electronic access to their health information (including lab results, problem list, medication lists, allergies) for at least 10% of patients.
  19. Provide clinical summaries to patients for at least 80% of all office visits.
  20. Demonstrate the capability to electronically exchange clinical information (problem list, medication list, allergies, diagnostic test results, etc.) by performing at least one test of transmission.
  21. Perform medication reconciliation at relevant encounters and each transition of care for at least 80% of relevant encounters.
  22. Provide a summary care record for each transition of care and referral for at least 80% of transitions and referrals.
  23. Demonstrate the capability to submit electronic data to immunization registries and actual submission where required and accepted, by performing at least one test of transmission to immunization registries.
  24. Demonstrate the capability to provide electronic syndromic surveillance data to public health agencies and actual transmission according to applicable law and practice, by performing at least one test of transmission to public health agencies.
  25. Protect & ensure the security of electronic health information by implementing appropriate technical capabilities, and conducting a security risk analysis, and implementing security updates as necessary.

We’ll tackle how Meaningful Use is defined for hospitals in tomorrow’s post….

Posted in ARRA, EMR, Implementation.

Tagged with , , , .


Don’t hire a CIO as your next CIO!

Seems counter-intuitive doesn’t it? Let me explain….

With our changing healthcare landscape, the “old skills” that were valuable to have in a CIO are no longer helpful (and may indeed be counterproductive). With the ARRA and with “healthcare reform” on the horizon, hospitals and physician groups need a “new breed” of CIO–one not steeped in technology, but one with a broader base of skills, encompassing not only technical ability, but business and (most importantly) clinical expertise as well.

Think about it….

Ten or twenty years ago, a CIO had to be technically skilled. “IT” primarily meant “hardware” and getting all the computers configured and networked (along with any communications infrastructure). In addition, CIOs managed technical teams–the guys (and gals) who could sit behind a computer terminal all day, and enjoyed coding and “twiddling the bits”.

Furthermore, corporate executives weren’t all that interested in technology–they knew email had to work and the accounting system had to provide reports at tax time, but as long as things didn’t break down most executives were happy to have a CIO that was able to “just take care of all that technical stuff”.

But somewhere along the way, our industry changed. We became more dependent upon technology–it became more than “just the email”–it became part of our core business.

But we never changed along with it.

For many of our organizations, we still have a technical expert as CIO, and that’s precisely the wrong fit for most healthcare organizations.

What happened?

Technology became integrated with clinical care.

Our physicians, nurses and allied health providers use and depend on technology to do their jobs. EMR, EHR, PHR, HIE, CPOE, LIS, HL7 and many more acronyms are now part of our lexicon, and are as important as a stethoscope and a sphygmomanometer in providing medical care. Simply put, clinicians can no longer provide modern medical care without technology.

And yet for many of our hospitals, the leaders providing that technology–our CIOs–have no clinical background.

Yes, it’s always been that way, and yes many of our current healthcare CIOs have “worked their way up” in the IT group, and yes they’re a “great guy”. They’re technically skilled, and can design a computer network, fix an email problem, configure a router and can manage to solve just about any other of a plethora of technical challenges an organization might face.

But do they understand what a physician does?

And more importantly, can they properly advise an executive team and recommend appropriate courses of action that will have a profound impact on clinical care without understanding how that care is provided or what is involved?

Are they still the “right” guy to help move your organization forward in our modern healthcare marketplace?

In a word–no.

A CIO without a clinical background becomes simply reactive in today’s healthcare environment.

They are not proactive–seeking solutions and understanding where technology can be leveraged to help provide better patient care. Without a clinical background they can only listen to the recommendations of others, be they physicians or others with clinical expertise. Then, without a clinical frame of reference upon which to rely, they must accept those recommendations, and incorporate them into their strategic planning, without the ability or understanding to provide or assess alternative solutions.

They react.

Someone else has to come up with the idea, and they simply implement it.

Indeed I recently had a conversation with a CIO who felt this was exactly his job–he had abdicated all participation in decision making, and wanted “the doctors” to decide on what they wanted, and whatever it was, he’d simply put up the servers and make sure the system turned on. He wanted to be told what to do, and then he and his group would configure the hardware and network, and install the software.

Of course one might argue that a good CIO would recognize this as a weaknesses, and incorporate folks with clinical expertise in his teams (and indeed we are seeing more of this in IT, especially as organizations begin implementing CPOE which requires an exceptional clinical understanding). But even then our CIO still remains reactionary, and has to rely on the internal experts on his team for advice and recommendations.

He’s never written a progress note, never taken a blood pressure, never been in an operating room–he’s never been “on the other side of the mask”.

He simply cannot relate to physicians and nurses, and what they need from technology in order to succeed (and worse still, they cannot relate to him). He cannot proactively help them–he must wait to be told what they need, and what to do.

To be truly effective, a healthcare CIO must have a clinical background.

“But those people don’t exist!”

Yes they do, but we don’t look for them (and of course if you’re not looking for it, you’re quite unlikely to find it!)

We and our HR teams focus on what we used to need–technical ability. We look for Microsoft or Novell certifications, and for someone that’s been a CIO before…but we don’t ask for clinicians. We have job descriptions for CIOs, and all of the characteristics that we think will make an effective healthcare executive.

But we don’t ask for a clinical background.

They’re out there–physicians and nurses that have embraced technology. Maybe they’re already in-house, perhaps part of your informatics group, or perhaps they’re working for a start-up technology firm or EMR vendor, or maybe they’re somewhere else–but they’re out there and you have to find them. We just have to recognize what that’s what we’re looking for, and partner with our HR teams and recruiters to target and find those skills.

A clinical background is simply imperative for today’s healthcare IT CIO.

Don’t place your next CIO without it.

Posted in Redlog Blog, Strategic Planning.

Tagged with .


Paired Programming & The New York Times Crossword Puzzle

As I was reading “A Deep Dive into Agile” by the folks at Menlo Innovations, I was intrigued by the story about a developer who enjoyed working on “hard” problems, who would “rather work on a problem for four hours than have someone help them solve it in five minutes”…

And I thought to myself–that’s exactly the issue…developers love the challenge–they like the puzzle–and the “fun” (and personal gratification for the developer) lies in solving the puzzle and not simply getting to the answer.

But for a business, it’s getting to the answer that really counts.

And then I thought a bit more about puzzles, and how we solve them…and thought:

What if we asked developers to solve the New York Times Crossword Puzzle?

We’ve all tried the NY Times Crossword (I’m not sure I’ve ever completed one, but for me they’re a good diversion for long plane rides). They’re long, cryptic and difficult to solve–a lot like designing a software application.

How would you approach having your development team solve a Times Crossword?

Would you give it to your most senior programmer, and have him solve the problem by himself?

This might be preferable to the developer–it’d be challenging, and fun to solve the puzzle. If he got ’stuck’ he could look at other rows and columns and ‘work’ the puzzle to try and ascertain the right word for the right clue. If he is talented and persistent, he might eventually get to finish the puzzle. The company would be happy as the problem would be solved, and he would have realized a good deal of personal satisfaction for being the savior, and the only one who could solve it.

And besides, the other developers could work on less challenging (but still important) activities, and overall corporate productivity would be enhanced.

Or would it?

What if we had two developers working on the same puzzle?

If we used this approach (as we typically do for software development) we’d divide the problem in half, and give each developer a piece of the puzzle (say the right and left halves of the crossword).

Each would work in isolation–each would ’solve’ their half of the puzzle, each conquering the challenges independently, resolving ‘getting stuck’ by themselves, and (if all goes well) the puzzle would be completed in less time, as the work required would have been distributed among two individuals.

And we’d consider this to be better–and applaud ourselves for our managerial creativity…

But this assumes we’ve divided the work appropriately!

What if–instead of the right and left halves of the puzzle–we divide the puzzle work into rows and columns?

After all–it seems logical–the clues are divided that way already!

Let’s just give one developer all the rows, and the other developer all the columns.

We’ve still divided the work among two developers, and we’re guaranteed to get a better result than one developer working in isolation…aren’t we?

Whoops! That’s not going to work!

The flaw of course with dividing the existing work among two or more developers is that it assumes that we know the best way to divide the work, and that we know and are aware of all of the interdependencies that might impact our solution at the start of the project (and most likely we don’t).

But we continue to use this methodology when developing software–divide the project, give a chunk to each developer, have them each code in isolation, and then we’re surprised when it never seems to come together at the end of the project.

But what if we used “Paired Programming” to solve the NY Times Crossword?

Think about it–what if our two programmers sat down side-by-side, with only one copy of the puzzle and clues to use between them?

There’d be a synergy we didn’t have before. Each person could immediately verify and confirm each other’s work. The two developers would be more confident that each word was “right”, and any disputed words could receive more attention (i.e. we’d have “built-in” quality assurance). And if either developer got ’stuck’ the other could help the team climb out (…”Hey Bill–What’s a five letter word for ‘efficient development’?”…)

And (I’m willing to bet you lunch) the puzzle would be solved faster with our two programmers working together than it would if we’d have them simultaneously working on separate portions of the puzzle (no matter how you decide to divvy it up).

And if we refocus the team, so that the satisfaction of ’solving the puzzle’ becomes a team process (rather than an individual pursuit) then Paired Programming becomes just as much (if not more) fun and rewarding for the developers.

And isn’t this (the solution of the puzzle in the quickest, most efficient way) what we’re trying to achieve as a corporation?

Seems obvious to me.

So then why do we continue to resist “Paired Programming” as a development methodology?

Makes you wonder doesn’t it?

Posted in Agile Development, Redlog Blog.

Tagged with .