EHR – Page 2 – Faith At Law LLC

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.

Meaningful Use Gets A Definition

The Centers for Medicare and Medicaid (CMS) and the Department of Health and Human Services have released for public comment proposed rules that help, among other things, to define “meaningful use” in the context of electronic health records systems. As astute readers will note, the federal government intends to start making incentive payments to qualifying providers in 2011 who can demonstrate meaningful use of a certified health record system. 2009 was spent trying to figure out just what that phrase means, and the proposed rules (available here) provide the first formal attempt at definition by CMS.

There are three stages of meaningful use, which must be demonstrated at various points during the incentive payout schedule, depending on when the provider adopts an EHR. If, for example, a provider adopted an EHR in 2011, the provider would be required to demonstrate Stage 1 compliance in 2011 and 2012, Stage 2 compliance in 2013 and 2014, and Stage 3 compliance in 2015 in order to receive the incentive payments from the Medicare program. (There is a helpful chart on page 46 of the draft regulations). If a provider were instead to adopt in 2015, they would have to demonstrate Stage 3 compliance. For those of you thinking about waiting a few years before adopting an EHR (apparently we “adopt” rather than “birth” these systems, though from the squeals of some users, I would think the pangs of birthing are a more appropriate metaphor), be forewarned: late adoption means the expectations are higher with regards to demonstrating meaningful use if you want to get an incentive payment.

Stage 1 requirements are described in the proposed § 495.6(c), and include the following items:

(c)(1) drug interaction checking

(c)(2) problem list

(c)(3) active medication list

(c)(4) active allergy list

(c)(5) basic patient demographics

(c)(6) record basic height, weight, blood pressure, BMI, and peds growth charts

(c)(7) smoking status

(c)(8) store lab results in structured data format

(c)(9) be able to produce a list of patients by disease condition

(c)(10) implement 5 clinical decision support rules based on provider specialty or priority

(c)(11) use electronic insurance eligibility

(c)(12) submit claims electronically

(c)(13) perform a medication “reconciliation”

(c)(14) provide a summary of care record for each referral, or “transition of care”

(c)(15) capacity to submit data to immunization registries

(c)(16) capacity to submit electronic surveillance data to public health agencies

(c)(17) comply with HIPAA security regs via risk assessment and mitigations

And if that wasn’t enough, section (d) gives some more rules to comply with:

(d)(1) use “computerized provider order entry”

(d)(2) send prescriptions electronically

(d)(3) report ambulatory quality measures to CMS

(d)(4) send patient reminders for preventive care

(d)(5) provide patients with electronic health record data on request

(d)(6) provide patients with timely electronic access to their health data

(d)(7) provide each patient a clinical summary at each visit

(d)(8) exchange data with HIE’s

There is a helpful chart of these requirements that starts on page 103 of the proposed regulations, and points out where the criteria vary depending on whether a hospital or individual provider is attempting to demonstrate compliance. The regulations also propose measures to demonstrate compliance with each requirement in Stage 1, which is included in the respective requirement’s section.

Now, you probably are wondering what the Stage 2 and Stage 3 criteria are. From my reading of the regulations, these have not yet been promulgated. CMS is, however, working on it. They even give you a teaser on page 109 of some potential Stage 2 requirements.

Many of these requirements are hardly a shocker (recording a patient’s name and their height, weight, and what medications they are on, for example). These core requirements are essential to any system purporting to manage health. There are, however, a number of very interesting requirements which may be much harder for systems to obtain. For example, requiring that 80% of patient insurance information be verified electronically may be quite a stretch (and in many cases, this is not handled by a health record system but instead by a practice management system).

Also, providing patients with electronic access to their health data within 96 hours of its receipt may also require a wave of web site, firewall, and secure socket layer certificate purchases by providers, many of whom do not support this kind of access today to their health record systems. And while it would be wise to perform a medication “reconciliation” at each visit, it is not clear how this would be accomplished from the regulations as written.

Stay tuned for additional postings on this very important topic! And be sure to send in comments to CMS on these rules based on your experiences with EHR technology in your practice.

From My Pen to Your e-Record

Vernon Huang, an anesthesiologist, and his company, Shareable Ink, have created a pen that both writes on paper, and transfers your writing to an electronic health record system through the use of a tiny camera in the pen that keeps track of what you are writing. (see article here) Given that a majority of health care providers still use paper records today as a way to document patient visits, a pen that allows for conversion to paper’s electronic cousin is a welcome improvement in the health records environment.

Dr. Huang also notes that the pen allows for the conversion of data into discrete data elements as part of the import process to the health record. So, for example, a medical assistant documenting a patient’s heart rate and blood pressure on paper with the pen can have those discrete data elements entered into the patient’s chart as individual data elements for reporting and analysis.

This invention is an interesting twist on EHR adoption issues. One of the main problems that users complain about is the loss of speed (or the sense of loss of speed) that results from having to use a keyboard and mouse to document patient care. This is particularly acute in practices that rely on high daily patient volumes to keep the doors open, such as the private practice of your family doctor, pediatricians, and some specialists (my dermatologist was done with me in 8 minutes flat, and that included me getting undressed).

There are other security concerns with a pen that makes entries into a database system (like non-repudiation – that we know who purports to be using the pen is really the person they say they are), but this invention may go a long way to moving resistant practices to an EHR. Remember – Medicare and Medicaid will pay between $50,000 and $60,000 per qualified health care provider in incentives for those that adopt an EHR and demonstrate “meaningful use.” Stay tuned.

The Quest for Meaningful Use

Section 4101 of the American Recovery and Reinvestment Act creates an incentives program for Medicare providers (and a penalty program after 2015 with regards to reimbursement) for EHR adopters. See this article from June 2009 on “meaningful use.” See also an earlier blog post on ARRA incentives here.

One of the provisions for receiving incentive payments is that the provider can demonstrate “meaningful use” of the EHR system. The section also requires that this meaningful use occur on a certified EHR system. The term “meaningful use” is not defined by the statute, except as follows: “(i) Meaningful Use of Certified EHR technology – The eligible professional demonstrates to the satisfaction of the Secretary, in accordance with subparagraph (C)(i), that during such period the professional is using certified EHR technology in a meaningful manner, which shall include the use of electronic prescribing as determined to be appropriate by the Secretary.”

The phrase is not defined by the statute, but presumably will be defined by the promulgation of a regulation by the Secretary of Health and Human Services. The thinking today is that meaningful use would be defined by the achievement of certain milestones over time by providers using EHRs. Initially, the focus would be on actually putting data into the system. With time, the definition would expand to being able to look at data trends over time and evaluate this data for trends. And eventually, providers would be required to have an actual impact on patient health outcomes. There is likely to be a similar movement within the private insurance world for providers, as in a “pay for improved outcomes” model, moving beyond just reducing the number of times someone comes to the doctor’s office (the old, HMO model of quality).

In more practical terms, a provider that wanted to demonstrate meaningful use would need to buy some software, take it out of the box, and actually use it to put some kind of data into it. Most likely, a more sophisticated system purchaser would give some thought to how that data would be organized within the computer system, with the goal of being able to get it back out again on demand. In the paper health record world, this is comparable to having a paper note to document the visit, and a separate flowsheet that is maintained to track certain kinds of lab results over time. The flowsheet is the manually created output which ultimately can be used to evaluate patient outcomes to treatment. For example, an HIV patient is routinely checked for his or her HIV viral load. A lower number (or an undetectable viral load count) is better than a higher one. HIV care providers also keep track of the number of CD4 cells in a given blood sample: a higher CD4 count is better than a lower one. Over time, these two values are related to each other, and also predict if a patient is doing better or worse with the disease.

An observant provider would educate the patient about these lab results and their implications for health, and demonstrate how close adherence to the schedule for taking HIV medications helps improve the patient’s health over time. An HIV provider would also be watching for unexpected changes in these values to determine if the patient should be evaluated for resistance of the disease to the current regimen. HIV is an expensive and high risk disease to manage; but it only gets more expensive if the patient’s condition is not managed appropriately (with lengthy hospital stays, complications and other health issues). In addition, a patient’s quality of life goes down the tubes with the progression of the illness; usually the side effects of the medications to treat the illness are the lesser evil.

An EHR can help to improve the efficiency of this quality and management process for providers. A well-designed and implemented system will place relevant lab values onto an electronic flowsheet which can be charted and analyzed over time, avoiding the time spent updating the paper forms and reducing errors in data entry. In addition, an EHR can present multiple views to the data depending on the patient’s health condition, and can help manage care to accepted standards by reminding providers of tests or actions that are due (such as annual pap smears, 10 year tetanus boosters, quarterly viral load testing, STD screenings, etc.) EHR’s can also cut down on duplicate tests being ordered (at least within a practice that uses the system) if a patient is seen by more than one provider over time, as all have access to the same information in the same format.

While not yet fully defined, meaningful use will likely lead our nation to more defined care standards, with incentives (and potentially penalties) for better outcomes. But a word of caution – patients ultimately have to make decisions about their own health. Not everyone is convinced that having a BMI over 30 is bad enough to warrant exercising an hour every day and cutting calorie intake by 25-50%. Or consider smoking, which leads to a fair amount of bad health outcomes over time, yet how many Americans still smoke? Penalizing physicians for the stupid choices that patients make is not fair, even though the health outcomes for these patients will be worse than if the patient had listened to their physician. Expect the definition for meaningful use to be published soon, but also expect changes over time, particularly on standards for health outcomes.

Lost Data in the Cloud: How Sad

The headlines are ablaze because somebody over at the company, Danger, upgraded a storage array without making a backup, and voila – bye bye T-Mobile contact data. (See the article on The Washington Post here) Nik Cubrilovic’s point in his article is that data has a natural lifecycle, and you should be able to survive without your contacts on your phone. But he also makes the point that all sysadmins have memories of not being able to recover some data at some point, and sweating out bullets as a result. His commentary is: this stuff is hardly as reliable as we expect it to be. “Cloud” computers are no different, except that they are generally managed by professionals that increase the odds of successful recovery as compared to the basement enthusiasts.

Having a backup plan is important. Testing your backups periodically is important. But generally, the rule is that the most important data gets the most attention. If you have to make a choice between backing up your T-Mobile contacts and your patient’s health records, the latter probably will get more attention. That’s in part because there are laws that require more attention to the latter. But it is also because you probably won’t die if you can’t call your aunt Susan without first emailing your mom for her number. You can die if your doctor unknowingly prescribes you a medication that interacts with something not in your chart because of data loss.

But the bottom line with this: data loss is inevitable. There is a tremendous amount of data being stored today by individuals and businesses. Even the very largest and most sophisticated technology businesses on Earth have had recent data losses that made the headlines. But the odds of data loss by doing nothing about backups are still higher than if you at use a cloud service. Oh, and if you use an iPhone with MobileMe, it synchs your contacts between your iPhone and your computer and Apple’s http://www.me.com, so you actually have three copies of your contacts floating around, not just a copy on the “cloud.” Maybe you T-Mobile people aren’t better off by “sticking together.”

Health Policy & U.S. Healthcare

I usually do not write about health policy in the U.S. because it is somewhat outside of my area of expertise, but I have been thinking about the issues with health care reform this year and thought I would provide some analysis. Watching the news, there seems to be a lot of resistance to health care reform this year. The cost for reform is one of the big stumbling blocks – given the actual price tag to the country that was floated by the various agencies charged with analyzing such things. However, if you think about it, our current, unreformed system of health care results in the insured paying for more than their own care.

For one, let’s talk about the uninsured. There are approximately 50 million Americans that lack health coverage today in the U.S. This does not mean that this people do not get any health care. To the contrary, well over 10 million Americans get health care from Federally Qualified Health Centers (FQHCs), a significant proportion of which are people without health insurance. In addition, there are a substantial number of other health care entities that provide health care to the uninsured at low or no cost, but are not yet federally qualified to do so. FQHCs are funded by the federal government today, at a cost of about $2 billion. We taxpayers pay for this. We are subsidizing this care today. Other entities that provide free or subsidized care do so through private grants, which some of us subsidize today through charitable donations, the United Way, or so forth.

Second, some have been claiming that health reform in the U.S. will just lead to a lot of people waiting around to get health care. At least in Maryland, by law, emergency rooms are required to treat whoever shows up in them, whether the patient is having a cardiac arrest or just has the flu. (See Md. Health-General Code Ann. 19-3a-02(b)(2)(vi) for freestanding emergency centers). Because of this, there are a fair number of patients that present to the ER who are uninsured. As an aside, economically speaking, emergency rooms tend to be loss leaders for the inpatient facilities to which they are attached. What this means is that the ER’s costs are not fully borne by the ER revenue stream from patients and insurers; much of the cost is actually covered by the patients that the ER can admit to the main hospital after initial workup and treatment by the ER physician. However, that also means that uninsured patients who present to the ER for a non-emergency health condition pass costs along to the main hospital which must be covered by inpatient operations, and by extension to those of us that are insured and go to that hospital.

For example, an uninsured patient that presents with the flu at the ER is treated and sent home. They may pay little or nothing for the visit, but the visit actually costs $800. The hospital covers this cost by charging a bit more for every patient who is actually admitted on a per day basis (or other costs that are charged in units). Some admitted patients won’t be able to pay either, so those that can also end up paying a bit more to cover uninsured admitted patients and uninsured ER-only patients. So if you have private insurance today, your rates are set in part based on the actual costs of providing health care to uninsured patients who can’t afford to pay on their own, because the hospital has to pass the costs of treating these patients to someone who can pay the hospital.

If health reform meant that everyone would now go to their local ER, regardless of what the condition or illness was, this would be a bad idea. Any time that I have been to an emergency room, there is a queue; the waiting room is always full no matter the time or the season. However, if health reform actually could redirect patients that do not have emergency health issues to an alternate resource that they could actually afford and would see them, this would help improve an existing “wait problem” for care today, while simultaneously reducing the actual costs borne by hospitals for non-emergent ER visits (which should mean that we can pay less per visit to the inpatient section of the hospital).

And speaking of waiting around – the truth is that even insured people tend to wait for health resources to be available under the current U.S. system of care delivery. Many doctors have 3-6 week lead times for scheduling in advance, their schedules are crowded with overbooks and double books, they often run late because of inefficiencies with the schedule and with administrative tasks; in short, competent physicians usually have too much demand for their services. This causes queuing. Health reform may not really be able to address this problem head on. Part of it is a technology issue; there could probably be developed a more sophisticated scheduling algorithm that would help to improve scheduling patients for care delivery, and allow for overflow to other providers, etc. But part of the problem is insufficient health care delivery points on the map. We apparently need more physicians to treat us.

Third, there are a fair number of U.S. personal bankruptcies each year (granting that the rates have been higher than normal this year because of the recession). Lack of insurance and a large, unpaid medical bill are a primary cause of personal bankruptcies. On the surface, if you haven’t filed bankruptcy yourself you might think that this has no effect on you. But bankruptcy is a bad thing generally. For one thing, the person who files for protection and has a $100,000 medical bill they have no hope of paying is injured because the cost to them for credit post-bankruptcy is considerably higher than pre-bankruptcy. In addition, a bankruptcy will limit the person’s job opportunities, will probably prevent them from gaining security clearance for sensitive jobs in the government, and otherwise limits their economic productivity within the U.S. economy, all of which is bad for the economy and for all of us.

But, in addition, that bankrupt’s medical bills are very unlikely to be paid through the bankruptcy proceeding. The hospital is likely an unsecured creditor, and they are at the end of the line with their hand out to the bankruptcy trustee. That “bad debt” is a cost to the medical provider, who will pass it along to patients in the future that will pay for medical care in the form of slightly higher unit costs.

The more bankruptcy filings, the more unsecured creditors that aren’t made whole who are health care providers, the higher the costs of care for everybody else. So again, us taxpayers are by and large the same people who actually end up paying the medical bills of the bankrupt, either out of our own pockets when we go to the hospital, or through higher health insurance premiums that our employers pass on to us each year, or through our taxes (think Medicaid and Medicare, both of which pay for inpatient stays, both of which are paid for by taxes, and both of which are billed at increasing rates by hospitals, in part to cover overall costs of providing care to patients without insurance who lead to bad debt for the hospital).

Fourth, there was this whole “death panels” claim about health reform, whereby the government was going to establish panels that would deny care to the elderly because they were too expensive. Of course, this is silly. If we were going to have such things, we would have a better name for them (maybe, “end of life decision making committee” or better yet “pull the plug on granny committee”, or something else that would be more catchy and might be more alliterative). But, really, this is tied into the idea that the government, through health reform, would stop a person’s doctor from treating the patient appropriately, perhaps because of cost, or just because the government bureaucrat was a nasty person. The whole matter is rather bizarre.

But, it also doesn’t speak to what goes on today. For example, there are committees that determine the priority and qualifications for patients to receive replacement organs because there is a long line and a short supply of organs available. Plenty of patients die each year for lack of an available replacement organ that was needed. (See this article for 2008 statistics on this issue) I don’t know that we call the committees “death panels,” but it is a classic example of a pre-existing queue that results in health care rationing.

Health insurance companies also make decisions about what they will pay for and what they will not. As far as I know, health insurers don’t decide to pull the plug on the elderly per se, but health plans do make choices for their insured patients about what services the patients will pay for out of pocket (or not receive at all if too expensive for the patient), what drugs are on and off the formulary (you may have to take the generic version of a pill, even if you’d rather take the brand name, for example), along with a host of other choices made ultimately to reduce overall costs to the plan. In our market system, I suppose you can change plans if you choose to, but because your health plan is often tied to your employer, that would usually mean changing jobs – which is not a very practical way to change your health plan.

So, this whole “death panels” thing is really about trying to “ration” care to patients so that more people get the basics, most likely at the expense of others that can pay for optional services. I’m sure that isn’t very palatable to patients with the means to pay for their thirteenth tummy tuck, but this is also, more or less, the status quo. Health care is rationed today by our insurers for most Americans. If health reform led to a more rational way to provide basic health care to more Americans, it would be the right thing.

And here is the other side to this: let’s say that we did institute a governmental body that would “ration” care. Such an entity is governed directly by the U.S. constitution and federal law. Do you really think that such a group would implement the “no life support for patients over 75” rule? Really?

To summarize, the U.S. spends about 16% of GDP on health care, which is substantially more than most other places in the world. Approximately $2.4 trillion (that is trillion with a “t”) is spent each year on this, or the total economic output of Italy. And ultimately, this money comes out of the pockets of those who can actually afford to pay for health care. By design, that means that those who can’t afford health care are being subsidized today by those that can. The challenge for health reform is to do a better job at cost redistribution than our present system, either by spreading out costs over a much larger pool (such as all 300 million Americans, rather than over the much smaller pools of employer-sponsored health plans today), increasing efficient delivery of health care (through technology that saves time or increases accuracy and reduces risk of harm), and/or perhaps encouraging more supply of health care providers to help meet the existing demand for services.

We’ll see what happens. Stay tuned for developments.

Reducing Health Care Inefficiencies

Can Health IT save us from ourselves? See the Yahoo Article on another assessment of health care spending in the U.S. and how much money is wasted in service delivery costs. According to this article, about 1/2 of the spending of the U.S. on health care is wasted in inefficient use of resources. Now, if you read the article, you will note that the top 8 items on their list only add up to about $600 billion, where the claim is that $1.2 trillion is lost (and you would think that a bunch of accountants could add, so maybe the journalists misread the fine print on the analysis), but even if you accept that much as the cost of inefficiency, that is more than it costs for the Medicare program in the U.S.

One of the big items on the list is inefficiencies with insurers who “magically deny” claims or otherwise require far too much in order for a provider to get paid appropriately. I find it interesting that this remains on the list of problems. In 1996, HIPAA was originally passed by Congress. Part of HIPAA was to mandate that, through regulation, standards be developed for the electronic transfer of information between insurers and providers of health care, including claims. The regulations eventually required that all or substantially all providers be able to submit claims electronically, which, one would expect, would be more efficient than the manual processing of paper claim forms.

So, if the auditors suggest that we still are wasting $200 billion per year on inefficient data exchanges with insurers, perhaps this deserves more focus.

Getting paid by insurers happens at the end of the process of service delivery to patients by providers. At the beginning, patients present to the doctor’s office with a problem, see a Medical Assistant or Nurse for preliminary weights and measures (like blood pressure and weight, etc.), see the physician, CRNP or physician’s assistant, who may then refer the patient to another provider, write a prescription, make other suggestions to the patient, require that the patient get lab work to rule out certain causes, and so on. At the conclusion of the visit, the physician will document, diagnose, and generate a financial transaction that must be processed and submitted to an insurer for payment.

The patient then will see other providers, the lab, the pharmacy, and perhaps come back for a follow-up visit with the physician. All of the steps in the process involve data transfer between several information systems, often housed in several different facilities, with different standards and different purposes. A key for a physician to get paid at all is to have accurate insurance information about the patient. Surprisingly, patients are not necessarily the best source of this information. However, insurers are apparently no better at knowing this on average. Otherwise, it would follow that we would already have regional databases or a national database of eligibility data available for all providers. I assert this because the standards for eligibility data have been around for a fair amount of time in the form of the ANSI X12 standard, but still there is a fair amount of lost dollars in the claims processing area of health care.

Perhaps this is so because providers want to get paid but insurers don’t have a good reason to pay them. Insurers do benefit from holding onto capital to accrue interest on it. The longer an insurer can do this, the more interest on the investment they collect, which goes straight to their bottom line. ARRA’s incentive system requires that physicians meaningfully use health IT and participate in some form of a health information exchange. But there is no comparable set of incentives for insurers to participate in HIE’s, or to incentive providers.

For example, this could be achieved by insurers preferring providers with health IT in place compared to those that don’t. Another example would be for insurers to pay incentives to providers for a higher degree of clinical outcomes (only possible if the providers can produce useful and independently verifiable data such as lab information, which is really only possible through the use of an HIE). The market may figure this out on its own, but I honestly doubt it. Perhaps the feds will pick up on this market failure and intervene to start improving efficiencies in this area in either health reform now or in ARRA part II in the next several years.

Understanding Health Information Exchange

I recently attended a break out session at the Centricity Healthcare User Group (CHUG) Fall meeting in Washington D.C. on health information exchange (HIE) in Oregon. HIE is an information system that allows individual health care providers to exchange data with trusted partners about patients shared among the partners. For example, clinical data about a patient in Oregon that goes to a local hospital and a specialty physician (like a cardiologist) can be shared via an HIE.

Health IT compatibility with an HIE is also a American Recovery and Reinvestment Act (ARRA) requirement for providers to receive incentive payments from Medicare or Medicaid under the Act. That means that a physician practice that buys an information system will need to contemplate how that system could interact with an HIE to be eligible to receive the $44,000 to $64,000 in investment money available through the ARRA starting in 2011.

HIE is an obvious step forward with health technology. Health IT started out as a localized solution to manual or paper processes in the offices of individual providers back in the bad old days of computing. That meant that the data collected was stored locally and was unavailable to other systems or individuals who might find it useful. For example, if you go to the doctor’s office, the office “registers” you to their system (paper or electronic), which means that you provide specific demographic information to the registrar. In the bad old days, you’d do this repeatedly every time you went to another physician or ancillary service (like the lab, radiology, etc.).

HIE presents a way for trading partners to be able to share this data, which helps to reduce the amount of time spent filling out forms for patients, and also reducing the administrative time required by each medical facility in keeping track of your address and insurance information. And, it should also increase the overall accuracy of the data stored across systems.

HIE also is aimed at clinical information. If you have a primary care and a specialist physician, both ought to know what medications you are taking, regardless of who the prescriber was. HIE provides a way to share this information automatically. The folks in Oregon have also implemented their HIE to support sharing problems and allergies, and it sounds like they are planning to implement methods to share other kinds of data in the future.

Maryland is in the process of developing its own HIE (see this press release from DHMH); HIE was a legislative priority to the Maryland General Assembly this year, which did result in a law mandating HIE in some fashion over the next several years. (See blog post on this topic here) More to come!

The Future of Health IT

An important aspect of President Obama’s health plan (partly funded through this year’s stimulus package) is health technology. As noted in a prior blog post, section 4101 of the ARRA provides qualifying health providers with Medicare reimbursement incentives for implementing Health IT that meets the statutory criteria set out in that section: meaningful use, participation in a health data exchange, and clinical outcomes reporting. By setting standards and providing incentives, the federal health policy will have a substantial impact on health care technology over the next five years, as billions of dollars are poured into health IT investment.

The question presented here is where will all of this public and private investment lead Health IT in the next few years?

Data Exchange And Availability

One of the areas of major emphasis in the ARRA is the ability of health care providers to more easily share information with other providers, patients, and others who have a legal right to receive such data. In particular, emphasis has been placed on the ability to transmit data to health exchanges, and to be able to produce data for the Feds on health outcomes (such as reporting hemoglobin a1c’s values over time to evaluate if a diabetic patient is responding positively to the care provided). Health data exchanges today are on the rise, according to ihealthbeat.org, up to 57 operational exchanges from 42 the year prior. These health exchanges are being used to exchange data between individual providers in an effort to improve care coordination and to improve care quality.

More specifically, for patients with several doctors who may specialize in a variety of treatments or health conditions, health exchanges have the potential to ensure that lab data ordered by one physician is made available in a secure and reliable manner to all the physicians involved in providing health care. Health exchanges also can ensure that a patient’s medical history (particularly their prescription history) is available in a consistent format to all care providers, saving time at each visit and reducing risks to patients that might forget a prescription or past medical procedure. Sharing lab results also has the potential to reduce costs and patient injury by reducing the number of duplicative tests ordered for the same patient by different providers. This is a common problem for patients with a coordinating care provider who end up in the hospital and the attending physician is stuck ordering duplicate tests.

Looking into the future, I would expect that health data exchanges (HDE) would become more prevalent so long as the total cost to implement and maintain the HDE are less than the costs saved/avoided by the data available in the HDE. One of the other factors that will impact the growth of HDEs is the number of peer-reviewed studies of their efficacy. Today, there is relatively little information on this topic because most HDEs are new or still under development, but in the next few years more definitive information should be available for analysis and review by eager technologists and researchers.

One of the great challenges for the HDE movement is maintaining patient privacy. HIPAA was originally implemented in part to specifically address patient privacy, as have a number of other state laws on this topic (for example, the Maryland Medical Records Act, See Md. Health-Gen. Code Ann. § 4-301 et seq.). And other states are getting in on the action to protect consumer privacy, including Massachusetts, Minnesota, and Nevada, just to name a few.

However, laws alone may not be enough to effectively regulate and protect the availability of health data. In the present HIPAA enforcement regulations (which were modified by ARRA this year), the top fines (where the act in violation of the security regulations was a negligent rather than an intentional one) are relatively low compared to the potential size of an HDE (for example, if a company like google or Microsoft was to become a dominant HDE) because the fines are a flat rate per incident rather than being scaled according to the company’s gross revenue or the severity of the breach or finding. The ARRA did move in the right direction this year by implementing a four-tiered approach to violations from the original enforcement authority under HIPAA, but further scaling may be required for this to become an effective deterrent to lax security practices.

Furthermore, having a patchwork of privacy laws increases the overall cost of compliance for HDEs, which increases the cost to implement these systems without necessarily improving the actual security of the information stored at the HDE. This is caused by regulatory requirements of overlapping but also potentially conflicting laws, along with the need to respond to multiple authorities with the right to audit or investigate the HDE (as larger HDEs will undoubtedly operate across state lines). Sadly, I imagine that this problem will probably get worse before it gets better, given the number of relatively autonomous sovereign powers within our country (5o states + the federal government) and the scope and scale of the privacy issue being considered.

Attitudes Towards Privacy

Our future privacy policies may also be impacted by the attitude of our youth to privacy today. Social networking sites, for example, allow for the exposure of a lot of information about the youngest among us, but the predominant users of these systems don’t seem to mind very much. Now, of course, facebook is not known for the health data available on its users, so who knows whether college kids would be posting their latest hemoglobin values as readily as they do about the parties they were attending and pictures snapped of them by the college paparazzi, but it stands to reason that the next generation’s attitudes towards privacy will be substantially different than the present one that has been called to govern the nation.

The result may be a reduction in the concern about privacy with an increasing criminal penalty for those that engage in theft of information. For example, perhaps instead of worrying as much about whether health data is squirreled away in an underground bunker with Dick Cheney, the future leaders of the nation will make this data generally available via the internet, ultimately reducing its value to would-be thieves. For myself, I can’t say it matters much if others know than I have high cholesterol and a family history of diabetes, but I also don’t think there is much stigma attached to either of these conditions as there might have once been (or might still be for other health issues).

Data Quality and Trusted Sources

HDEs will also need to address head on the quality and reliability of data stored in their databases. Today, data systems do not generally go beyond the initial setup of some kind of private network and the file formats that are acceptable for data to be exchanged. Inherently, one system trusts the data it receives from the other and merely re-publishes it into its own database, identifying the source of the data. Usernames and passwords may just not be enough for everyone to know that the data being sent or received is accurate and reliable.

In addition, even though HIPAA (and some other laws) have placed a small emphasis on technical encryption, the truth is that little has really been done with these technologies for most systems today to ensure that data entered is not repudiated later by the person that purportedly entered it. For example, many commercially available database systems are not natively encrypted. Local area network activity on the wire is rarely encrypted, again relying on the border security devices to keep outsiders out of LAN activity. Passwords are not consistently complex across an enterprise (especially where multiple database systems maintain their own passwords and accounts), and certainly cannot reasonably be changed frequently enough to ensure the password has not been compromised (without the user community revolting against the IT staff). And users routinely share passwords even though there is a federal law against it and in spite of the numerous repeated messages from system administrators to not share passwords.

Furthermore, data exchanged between systems relies on the initial configuration of the networking that connects the two systems to remain uncompromised. There is no further system verification to ensure that messages actually received across these systems are correct in the typical data exchange design. TCP itself was designed with a checksum in each packet, but that only tells the receiver if the packet received matches what was intended to be sent, not whether the data sent is coming from the human/system source alleged (e.g., the laboratory technician or physician that actually created the entry in the first place).

I anticipate that the future of authentication will be to move towards far more sophisticated and multi-level authentication (even though the biometric movement seemed to have lost steam, at least in the general consumer market). For example, instead of or in addition to a username/password, systems may also generally implement a token, or other physical card to grant access (such systems exist and are in general use today for some systems). Other security measures may involve thumbprints or biometrics. I would also imagine that more sophisticated encryption algorithms could be used beyond 128-bit cipher, and that encryption might occur at a more basic level than it does today (if transmissions are encrypted at all). For example, databases themselves may be encrypted at a record or table level, or application access could be managed through an encrypted socket instead of plain text as many operate now.

Beyond user access to put in data, surely there be could some additional layer of verification that could occur once data has been received from a producer system which could be, by design, independently verified before being committed to the receiving system. The alteration (or just erroneous entry) of data in transport from one system to another creates the real possibility of a bad health care decision by professionals using the data. This is certainly one of the major weaknesses of consumer level HDEs such as those from google or Microsoft which must rely on the consumer to enter their own lab and pharmaceutical information into the database when that data is not available electronically, or on data providers that rely on administrative or clerical staff to actually do the data entry without further review before distribution.

HDE Information Security

Today, a number of technologies exist that allow for data backup and redundancy to ensure that systems can be highly available and resistant to significant environmental or system disasters. One category of technology is called “cloud computing,” which is a kind of modern equivalent to what application service providers (ASP) of the 1990’s were offering, or what the ancient mainframes of yesteryear offered to computing users back in the bad old days of the 1970’s. What is fundamentally different today, however, is the possibility of having massively redundant and distributed information systems that belong to a cloud, where both ASPs and mainframe computing was often centralized into one server room or series of server rooms in one facility.

A common example of computing in the cloud today is gmail, which is an email service provided by google for free to consumers. There are still, somewhere, servers connected to the internet and controlled by google that will respond to SMTP requests, but google most likely has these servers distributed all over the planet and connected to a larger, redundant network infrastructure. Data stored on these servers are likely real-time replicated so that all gmail replication partners are up to date, regardless of which one you actually connect to when you use your web browser to navigate to your email account. Gmail has been around for some time now, and there are a fair number of users (26 million according to one article as of last September; wikipedia claims there are 146 million gmail users each month as of July 2009). Perhaps Health IT will be the next internet “killer app.”

And looking down the road, the future of Health IT likely involves some kind of “cloud computing” model where health data is not stored locally on an organization’s server. This model will provide for additional flexibility with data transfer, improved system redundancy, and higher availability than is typically possible in a single enterprise or within a single server room.

Cloud computing, however, does pose other security and privacy concerns. (See this article on CNET that addresses some of these same concerns) For example, will staff of the cloud computing service have some kind of access to the actual data entered into the system? Will these systems have a way of keeping those administrators from changing or accessing data (for example, by encrypting the data to place it out of reach of administrators)? Who is liable for loss of the data? Will the HDE seek to (and will courts and lawmakers allow it to) unreasonably limit liability for unauthorized access? Will the HDE be indemnified by a government agency? Will the HDE pay for itself by allowing advertisers access to data stored by the HDE? Will it utilize a more democratic approach (for example, as facebook has recently been employing to ratify adoption of changes to policies in place that affect its user community)?

Stay tuned.

Health IT Implementation – an Overview

Health IT has been put back into the forefront of the Obama national health care initiative, in part because of Medicare incentives built into the ARRA for health care providers that implement and meaningfully use a health technology system in the next few years. The cost savings is premised in part on the success of the installation and implementation of the information system to be used by health care providers. This article will focus on some of the details of implementing an electronic health records system, along with some of the pitfalls that can keep a project from being completed successfully.

The End Goal is Meaningful Use

In order to receive reimbursement from the Medicare program, the ARRA requires that a provider demonstrate meaningful use of the system, connection to a health data exchange, and submission of data of clinical quality measures for patients at the practice. (See earlier post on this issue) Reaching these goals goes beyond the mere technical installation of some computer system; “meaningful use” in particular will likely require health care providers to show that the actually use the computer system in managing patient care, reducing errors, and improving health outcomes for individual patients. Getting there requires effective planning for the project and a productive implementation process.

The good news for providers who want to implement an EHR is that: (a) the data a provider needs to effectively see patients will be available when you need it (no more “lost chart syndrome”), (b) the chart documentation will support the diagnosis and E&M codes billed to the insurer, (c) EHRs can be tightly integrated with a practice management system to reduce data entry errors and improve billing, (d) most EHRs will make clinical or mandated reporting easier as compared to paper charts, (e) lab results can be electronically imported into the EHR from major lab providers, (f) improved E&M coding can lead to better reimbursement, and (g) an EHR investment can be viewed by your staff as an investment in them, leading to higher staff retention rates and satisfaction. But there is a cost to achieving these benefits.

For one, some of the office workflows for handling patient care may need to be modified or adjusted to incorporate the EHR. Some workflows that operate on paper in an office will not convert efficiently to a computer system. Forms used to process or document patient care may also need to be modified when they are converted into the EHR. EHR installations for health care providers tend to expose workflow problems and breakdowns that require attention in implementation for the project to be successful.

Secondly, all the staff in the office will need to be computer literate, and generally, physicians and other health care providers will need to be able to use a computer effectively while examining their patients. This has become less of an issue as more doctors and other providers are trained to use a variety of computer systems at medical school, but computer literacy is still a major issue for some practices in the nation.

Third, EHR projects are high risk – there is a substantial chance that the project will be derailed for any number of reasons, including a lack of a process for effectively making key decisions, office politics, the capital expense to acquire computer hardware and software, and a lack of technical expertise among the implementation team, among other challenges. These can be overcome or at least mitigated by sufficient advanced planning by the organization.

And finally, most studies of EHR installations suggest that your practice will be in the minority of practices using an EHR (though there has been an improvement in the market penetration here over the last few years). This is partly because of the expense of implementing the systems, and the longer-term costs of maintaining them.

You can get there if you have a good plan.

Manage Expectations Early and Often

No, an EHR will not solve your workflow problems without your help. An EHR is not free, even if licensed under an open source software license. The data that is collected in the EHR is useful, but will require further technical assistance to be useful for research or analysis. Staff can’t keep doing things the same way and expect a different outcome (besides this being one definition of insanity, EHRs are not magical beasts with wings, and magical thinking does not lead to a happy end user). Doctors won’t be able to see 50 patients per day after install if they were only able to manage 20 per day before. A project that lacks goals that are attainable will fail.

Any system project can be a victim of unreasonable or unrealistic expectations. Those leading the project need to be frank about what can be achieved and at what cost to the staff using the EHR. Expectations can be managed by establishing tangible goals and having a workable project plan with real milestones and a clear assessment of the resources (financial and staff time) that will be needed to reach each one. For example, implementing the EHR two months from purchasing it can be realistic, but only if the provider’s office is prepared to commit significant time to the planning and installation, particularly in identifying forms that need to be developed electronically and lab interfaces that need to be installed (two of the most time-expensive portions of an EHR implementation). The need for effective training can also not be understated – staff should not expect they can pick up use of the system in an hour or two, or learn as they go with live patients in the room.

Picking an Information System

Finding the right EHR is an important task and should not be left to chance. There are a lot of EHR vendors in the market place today with a variety of installations, history, and effectiveness. Developing a written request for proposal and requiring an objective process for evaluating responses to the RFP is essential to fairly evaluate the vendors in the market place. Sending the RFP out to 100 vendors is also not helpful, nor is having a 100 page requirements section. But your prospective partner for this project should be able to effectively respond to your RFP and explain in satisfactory detail what the options and costs are for implementing the proposed system.

Furthermore, your organization should form a search committee that is comprised of enough staff to provide meaningful input on the responses to the RFP, and to interview qualified vendors to assess for the needs of the essential practice areas. Vendors should also be able to competently demonstrate their project to the committee’s satisfaction, so that the committee can identify the best two candidates for the job.

To help encourage staff buy-in (where your facility is sufficiently large that the search committee may not represent all interests), I have also recommended that the finalists demonstrate their product to all staff, and to put the final decision to a group vote. This doesn’t work in all organizations, but the more effort you put into including the staff that use the system in the process, the more buy-in to the project you will garner, which increases the odds of a successful implementation.

Vendor Negotiations

Once you have identified the best candidate EHR, your organization should begin to examine the terms of the contract with the EHR vendor. Most vendors have a standard form contract that describes the terms of the relationship, particularly for ongoing support and updates to the product. These contracts are complicated and an attorney can be helpful to ensure that the contract fairly represents the relationship, costs, and promises made by the vendor along the way.

Negotiations can take some time to complete, particularly where multiple parties are involved or there are substantial costs involved. Hammering out contract details with the vendor is an important step in the planning process.

Major Milestones

Once a vendor has been chosen, most EHR implementation project plans will have the following major milestones to get to a successful go live: (a) form a planning committee, (b) form a technical team, (c) review and make decisions on the requirements for the project, (d) install the server, software, and workstation software, (e) develop all required clinical content (such as electronic forms, flowsheets, and data requirements) for go live, (f) implement all interfaces for data flowing in and out of the EHR, (g) conversion of all charts from paper into the EHR, (h) staff training completed, and (i) go live with the system.

The planning committee should include the clinical departments that will be using the system, and should be designed to regularly meet up to and through the go live date. The committee should be charged with enough authority to make decisions about the project’s implementation, and should become your initial group of “super-users” or staff with more training about the EHR. Your super users should then become sources of information for the rest of the staff as they work through integrating the EHR into their practice.

The technical team is comprised of the IT staff that are responsible for installing the server and workstation equipment, getting the EHR software and database installed properly, configuring interfaces between systems, and installing any supporting network or peripheral technology. This team should regularly report to the planning committee or the project manager for the installation.

The planning committee is responsible for making the decisions about how the EHR will be implemented. The vendor supplying the system should regularly participate in the committee’s meetings, and generally the project manager should chair the committee. Actions and decisions of this committee should be documented and distributed to the members. In my experience, the meetings of the committee or geared toward training the members on the details of the EHR so that they can determine how the system should work for their departments. These meetings can be contentious as a number of people will need to agree, but in the longer term, this process helps to make sure that the project is implemented appropriately.

This committee also should be responsible for identifying project priorities. The reality is that no EHR implementation can go live with every request ready – there are always too many requests and not enough time to implement all of them. This committee should be prepared to identify what’s most critical and clarify these priorities to the staff involved in the installation.

In addition, this committee should be committed to be thorough and address concerns along the way with specific implementation decisions and priorities. Some decisions made early on can be very time consuming and costly to correct later.

The “clinical content” of the application includes the electronic forms that will be used to document care, the organization of the sections of the EHR that display structured data (such as lab results for a patient), and other functional areas of the EHR that are susceptible to modification at implementation. This development may be handled by the vendor. However, post-go live may require the provider to maintain the content developed during implementation, or be in a position to add new content. In some cases, third parties may be able to sell premade clinical content separately from the EHR vendor. All of this customization of the product requires special attention to ensure that the content developed meets user requirements and that the content is developed according to standards acceptable to standard practice.

Most EHRs support some interfacing with other products, using a common language like HL7. If interfaces with other software or third parties is essential to the implementation, substantial lead time and attention to detail is required for these interfaces to be ready at the go live date for the project.

Some meaningful portion of the existing paper charts will need to be converted to electronic format into the EHR, prior to go live if at all possible. This is a very time-intensive process, and is often used as a training opportunity for users, who can be scheduled to convert specific charts as part of learning how to use the EHR. However, most practices have many more charts than users available to convert them, and many project planners will budget additional resources to aid in the paper conversion process.

Some practices opt to extract specific data from a paper chart into electronic format, using specialized clinical content for this purpose. Other practices may simply scan and index the paper chart documents as is into an electronic document and attach it to the chart as the chart history. Still others will do a hybrid of these two solutions.

Training is also a very important aspect of any EHR implementation. From my experience, up to 20 hours of training may be required for super users of the EHR; the minimum is about 4 hours for sufficient exposure to the basics of an EHR. Depending on the total staff to be trained, scheduling training classes for an organization may be a substantial time committment. Generally the EHR vendor can give guidelines on the minimums for training to gain proficiency on the system. Note that no implementation’s training will end at go live; generally post go-live training and ongoing training for new staff after the system is implemented are ongoing expenses of the EHR.