Meaningful Use – Some Thoughts

HHS and CMS have released the regulations as promised to help define the phrase “meaningful use” that can be found within ARRA and will determine which health care professionals have been naughty and will receive no incentive payments from Uncle Sam, and those that have been nice and will.  The regulations themselves are long.  I can’t be critical on length alone; the regulations reflect the complexity of the area they intend to regulate.  To date, the regulators have drafted the Stage 1 measures for meaningful use.  These measures will determine whether the relatively early adopters of EHRs will receive incentive payments under Medicaid or Medicare (if the provider otherwise qualifies).

This post takes a closer look at the Stage 1 criteria.  There are a number of requirements that are basic to any self-respecting EHR, such as §§ 495.6(c)(1) drug interaction checking, (2) a problem list for each patient, (3) a medication list, (4) an allergy list, (5) basic patient demographics, (6) basic vital signs, and (7) the patient’s smoking status.  Most systems will store this kind of data in discrete data fields and can make this information available to be queried for reporting.  Section 495.6(c)(8) mandates that lab data reported back to the provider be stored in a structured format.  This is also a basic dimension of an EHR, though it takes more effort to get this to work efficiently (including someone with the job of maintaining the mappings that take reported lab results and place them in specific data elements in the database).

Section 495.6(c)(9) mandates that the provider be able to generate a list of patients by disease state.  Assuming that patient diagnoses are stored in a structured format, this also should not be too difficult to address with most systems.  The medical staff would need to provide some data definitions (for example, the diagnosis codes 042 and V08 both mean HIV; a series of diagnosis codes that start with 250 mean diabetes, and so on).

Section 495.6(c)(10) mandates that there be five decision support rules that can be built into the EHR and that are specialty or priority-specific.  For example, all HIV patients in care should have an HIV viral load test performed at least every 4-6 months.  Some systems may not support these kind of point-of-service reporting tools (so that the provider is reminded when in the exam room with the patient), but presumably a reporting tool that generated reminders to patients to receive a particular test or service might meet this requirement.

However, the regulations take a turn at (c)(11) when they mandate the use of electronic eligibility data and the submission of electronic claims data.  These are both not the typical province of an EHR, but of a practice management system.  And while there have been ANSI standards for electronic eligibility data published for years, there are still some insurers that cannot produce useable data for eligibility verification.

Section 495.6(c)(13) calls for a medication reconciliation at each office visit with the patient.  I presume the intent here is to have the provider ask the patient to verify that all these pills listed in the EHR are really what the patient is taking.  I’m not sure asking this question at every visit will be practical with every patient – particularly with the patients at the most risk for interactions – those on a large number of different drugs.  Health information exchanges may help to tame some of this by presenting to the physician listings of drugs associated with the patient from multiple sources, but truthfully, this may quickly become bewildering for both the patient and provider.

Section 495.6(c)(14) calls for a record summary to accompany each referral for specialty care.  With the paper referral system today, this will increase the amount of paper shared between practices.  I would hope this requirement would push more providers into participating in an HIE so that this kind of thing could be shared electronically.

Section 495.6(c)(15) and (16) are addressed to sharing data with certain governmental agencies for tracking patient immunizations and reportable diseases that are surveilled by local health departments.  Presumably both of these would be better addressed by having the government agency participate as a recipient of data from an HIE, rather than building an interface directly from a provider to the agency requesting the information.  The issue here, however, is that the items to be reported are probably not likely to be initially available from the HIE because these data elements may or may not be consistently stored across EHR systems (particularly immunizations; reportable conditions are often keyed to a particular diagnosis code, such as the codes for syphilis or HIV, and problem lists are more often consistently stored as structured data).

And, even though risk assessments have been mandated since 2003 within the HIPAA security regulations, CMS felt that this specific requirement needed to be reiterated within the meaningful use regulations.  My guess: most providers don’t regularly perform risk assessments because they are time-consuming, and information systems change to frequently for the risk assessment process to keep track.

Section 495.6(d) provides another 8 requirements for providers.  Notably, the regulations mandate direct patient access to their health record chart electronically, and the ability to feed data to patients on request (for example, for patients with a personal health record that want to get a live feed of lab results and medications from their doctor).

Overall, the regulations are substantial.  Some of the requirements in the regulations will cause some consternation for providers and will likely lengthen the time to implement EHRs for some organizations that were focused on the basics of just getting the visit documented in the system.

Published by


Maryland technology attorney and college professor.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.