EHRSelector Blog

What's New on the EHRSelector Blog

By

Restructure and Reform Meaningful Use: Here’s a Way

Note: This was originally posted on EMRandEHR.com

It’s no secret that ONC’s meaningful use program’s a mess. I’m not sure there is an easy way out. In some respects, I wish they would go back and start over, but that’s not going to happen. They could do something to see daylight, but it won’t be either easy or simple. As I‘ll outline, ONC could adopt a graduated system that keeps the MU standards, includes terribly needed interoperability and usability standards, but does not drive everyone crazy over compliance.

MU’s Misguided Approach

ONC has spent much time and money on the MU standards, but has painted itself into a corner. No one, vendors, practioners or users is happy. Vendors see ONC pushing them to add features that aren’t needed or wanted. Practioners see MU imposing costs and practices that don’t benefit them or their patients. Users see EHRs as demonic Rube Goldberg creations out to frustrate, confuse and perplex. To boot, ONC keeps expanding its reach to new areas without progress on the basics.

Most the MU criticisms I’ve seen say MU’s standards are too strict or too vague. Compliance is criticized for being too demanding or not relevant. Most suggested cures tinker with the program: Eliminate standards or delay them. I think the problems are both content and structure. What MU needs is a return to basics and a general restructuring.

Roots of the MU Program’s Problems

It’s easy to beat up on ONC’s failures. Almost everyone has a pet, so I’ll keep mine short.

MU1: Missed Opportunities. MU’s problems stem from its first days. ONC saw EHRs as little more than database systems that stored and retrieved encounters. Data sharing only this:

Capability to exchange key clinical information (for example, problem list, medication list, medication allergies, diagnostic test results), among providers of care and patient authorized entities electronically.

Compliance only required one data exchange attempt. ONC relied on state systems to achieve interoperability. Usability didn’t exist.

MU2: Punting the Problems. ONC’s approach to interoperability and usability was simple. Interoperability was synonymous with continuity of care and public health reports. Every thing else was put off for future testing criteria.

ONC’s usability approach was equally simple. Vendors defined their usability and measurement. The result? Usability’s become a dead topic.

Interoperability

ONC has many good things to say about the need for interoperability. Its recent Roadmap is thoughtful and carefully crafted. However, the roadmap points out just how poor a job ONC has done to date and it highlights, to me, how much ONC needs to rethink its entire MU approach.

Changing ONC

In one of his seminal works on organizations, C. Northcote Parkinson said it’s almost impossible to change a failing organization. His advice is to walk away and sew salt. If you must persist, then you should adopt the heart of a British Drill Sergeant, that nothing is acceptable. Alas, only Congress can do the former and I’m way too old for military service, so I will venture on knowing it’s probably foolhardy, but here goes.

New Basic Requirements

A better approach to MU’s core and menu system would allow vendors to pick and choose the features they want to support, but require that all EHRs meet four basic standards:

  1. Data Set. This first standard would spell out in a basic, medical data set. This would include, for example, vitals, demographics, meds, chief complaints, allergies, surgeries, etc.
  2. Patient ID. A patient’s demographics would include a unique patient identifier. ONC can use its new freedom in this area by asking NIST to develop a protocol with stakeholders.
  3. Interoperability. EHRs would have to transmit and receive, on demand, the basic data set using a standard protocol, for example, HL7.
  4. Usability. Vendors would have to publish the results of running their EHR against NIST’s usability standard. This would give users, for the first time, an independent way to compare EHRs’ usability.

All current EHRs would have to meet these criteria within one year. Compliance would mean certification, but EHRs that only met these criteria would not be eligible for any funding.

Cafeteria Program. For funding, vendors would have to show their EHR supported selected MU2 and MU3 features. The more features certified, the more eligible they’d be for funding.

Here is how it would work. Each MU criteria would have a one to ten score. To be eligible for funding, a product would have to score 50 or more. The higher their score, the higher their funding eligibility.

Provider Compliance. Providers would have a similar system. ONC would assign scores of one to ten for each utilization standard. As with vendors, implementing organizations would receive points for each higher utilization level. That is, unlike current practice, which is all or nothing, the more the system is used to promote MU’s goals the higher the payments. This would permit users to decide which compliance criteria they wanted to support and which they did not.

Flexibility’s Advantages

This system’s flexibility has several advantages. It ends the rigid nature of compliance. It allows ONC to add new criteria as it sees fit giving it freedom to add criteria as needed or to push the field.

It achieves a major advancement for users. It not only tells users how products perform, but it also lets them choose those that best fit their needs.

Vendors, too, benefit from this approach. They would not only know where they stood vs. the competition, but would also be free to innovate without having to include features they don’t want.

By

The New Congressional Rider: Patient ID Lemonade?

Note: This was originally posted on EMRandEHR.com

Also: Previous versions referred to Rand Paul as the author of the first congressional rider. That was in error. The first rider was authored by then Representative Ron Paul. I regret the error. CB

Last month, I posted that Ron Paul’s gag rule on a national patient identifier was gone. Shortly, thereafter, Brian Ahier noted that the gag rule wasn’t dead. It just used different words. Now, it looks as if we were both right and both wrong. Here’s why. Paul’s rider’s gone, but its replacement, though daunting, isn’t as restrictive.

The gag rules are appropriation bill riders. Paul’s, which began in 1998, was aimed at a HIPAA provision, which called for identifiers for:

…. [E]ach individual, employer, health plan, and health care provider for use in the health care system. 42 US Code Sec. 1320d-2(b)

It prohibited “[P]lanning, testing, piloting, or developing a national identification card.” This was interpreted to prohibit a national patient id.

As I noted in my post, Paul’s language was dropped from the CRomnibus appropriation act. Brian, however, found new, restrictive language in CRomnibus, which says:

Sec. 510. None of the funds made available in this Act may be used to promulgate or adopt any final standard under section 1173(b) of the Social Security Act providing for, or providing for the assignment of, a unique health identifier for an individual (except in an individual’s capacity as an employer or a health care provider), until legislation is enacted specifically approving the standard.

Gag Rule’s Replacement Language

Unlike Paul’s absolutist text, the new rider makes Congress the last, biggest step in a formal ID process. The new language lets ID development go ahead, but if HHS wants to adopt a standard, Congress must approve it.

This change creates two potential adoption paths. Along the first, and most obvious, HHS develops a mandatory, national patient ID through Medicare, or the Meaningful Use program, etc., and asks congress’ approval. This would be a long, hard, uphill fight.

The second is voluntary adoption. For example, NIST could develop a voluntary, industry standard. Until now, Paul’s rider stopped this approach.

NIST’s a Consensus Building Not a Rulemaking Agency

NIST’s potential ID role is well within its non regulatory, consensus standards development mandate. It could lead a patient ID building effort with EHR stakeholders. Given the high cost of current patient matching techniques, stakeholders may well welcome a uniform, voluntary standard. That would not solve all interoperability problems, but it would go a long way toward that end.

Congress has loosened its grip on a patient ID, now its up to ONC, NIST, etc., to use this new freedom.

By

Congress Getting Real About Interoperability Kills Paul Gag Rule

Note: This was originally posted on EMRandEHR.com

Correction: Brian Ahier looked at this post and made a better search through the legislation. When I searched, I used the same words that had been in use since 1998, which mentioned HIPAA and a national ID. As you can see in his post, the new language does not. I did not use the health ID language. I apologize for the error and thank him for his correction.

Sometimes what Congress leaves out is as important as what it puts in. The CRomnibus Act has an example for HIT. In its hundreds of pages, Congress took three actions to promote HIT interoperability. Two have been widely reported: It ordered ONC to report on interoperability data blocking and to spell out other impediments.

The third action, which I haven’t seen reported, was an omission. Ron Paul’s patient ID gag rule is no more.

In 2000, then Representative Paul (R-TX) put a rider on HHS’ appropriation blocking HIPAA’s call for a unique, patient ID. It prohibited, “planning, testing, piloting, or developing a national identification card.” Given Paul’s statements, this meant no patient ID development. By making it impossible to even think about an ID, ONC could not assess the full range of interoperability options.

Each spending bill since 2000 has had the rider, until now. Noting remotely similar is in the bill. I’m still trying to find out who and when dropped this.

What’s clear, though, is that Congress is serious about interoperability and has given ONC a clear field to develop a real plan. A bad gag rule is gone.

By

Adverse Event Reporting and EHRs: The MEDTECH Act’s Effects

Note: This was originally posted on: EMRandEHR.com

EHRs and Adverse Events

Medical systems generate adverse event (AE) reports to improve service delivery and public safety.

As I described in this note’s first part, these reports are both a record of what went wrong and a rich source for improving workflow, process and policy. They can nail responsibility not only for bad acts, but also bad actors and can help distinguish between the two. The FDA gathers AE reports to look for important health related patterns, and if needed to trigger recalls, modifications and public alerts.

EHRs generate AEs, but the FDA doesn’t require reporting them. Reporting is only for medical devices defined by the FDA and EHRs aren’t. However, users sometimes report EHR related AEs. Now, there’s proposed legislation that would preclude EHRs as medical devices and stop any consideration of EHR reports.

MEDTECH Act’s Impact

EHRs are benign software systems that need minimal oversight. At least that’s what MEDTECH Act’s congressional sponsors, Senators Orrin Hatch (R- Utah) and Michael Bennett (D- Colorado) think. If they have their way – and much of the EHR industry hopes so – the FDA can forget regulating EHRs and tracking any EHR related AEs.

EHRs and Adverse Events

Currently, if you ask MAUD, the FDA’s device, adverse event tracking system about EHRs, you don’t get much, as you might expect. Up to October, MAUD has 320,000 AEs. Of these about 30 mention an EHR in passing. (There may be many more, but you can’t search for phrases such as “electronic health,” etc.) While the FDA hasn’t defined EHRs as a device, vendors are afraid it may. Their fear is based on this part of the FDA’s device definition standard:

[A]n instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

…[I]ntended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals…

I think this section clearly covers EHRs. They are intended for diagnostic, cure, mitigation, etc., of disease. Consistent public policy in general and a regard for protecting the public’s health, I think, augers for mandatory reporting of EHR caused AEs.

Why then aren’t EHRs devices that require AE reporting? In a word, politics. The FDA’s been under pressure from vendors who contend their products aren’t devices just software. They also don’t want their products subject to being criticized for failures, especially in instances where they have no control over the process. That may be understandable from a corporate point of view, but there are several reasons for rejecting that point of view. Consider what the FDA currently defines as a medical device.

Other Devices. The FDA captures AE reports on an incredible number of devices. A few examples:

  • Blood pressure computers
  • Crutches
  • Drug dose calculators
  • Ice bags
  • Lab gear – practically all
  • Robotic telemedicine devices, and many, many more.

ECRI on EHR Adverse Events

The respected patient safety NGO, the ECRI Institute, puts the issue squarely. Each year, it publishes its Top Ten Health Technology Hazards. Number one is inadequate alarm configuration policies and practices. Number two: “Incorrect or missing data in electronic health records and other health IT systems.” Its report says:

Many care decisions today are based on data in an electronic health record (EHR) or other IT-based system. When functioning well, these systems provide the information clinicians need for making appropriate treatment decisions. When faults or errors exist, however, incomplete, inaccurate, or out-of-date information can end up in a patient’s record, potentially leading to incorrect treatment decisions and patient harm. What makes this problem so troubling is that the integrity of the data in health IT (HIT) systems can be compromised in a number of ways, and once errors are introduced, they can be difficult to spot and correct. Examples of data integrity failures include the following:

  • Appearance of one patient’s data in another patient’s record (i.e., a patient/data mismatch)
  • Missing data or delayed data delivery (e.g., because of network limitations, configuration errors, or data entry delays)
  • Clock synchronization errors between different medical devices and systems
  • Default values being used by mistake, or fields being prepopulated with erroneous data
  • Inconsistencies in patient information when both paper and electronic records are used
  • Outdated information being copied and pasted into a new report Programs for reporting and reviewing HIT-related problems can help organizations identify and rectify breakdowns and failures.

ECRI spells out why AE reporting is so important for EHRs:

…[S]uch programs face some unique challenges. Chief among these is that the frontline caregivers and system users who report an event—as well as the staff who typically review the reports—may not understand the role that an HIT system played in an event…

The MEDTECH Act’s Effects

The move to curtail the FDA’s EHR jurisdiction is heating up. Senators Hatch and Bennett’s proposed act exempts EHRs from FDA jurisdiction by defining EHRs as passive data repositories.

Most industry chatter about the act has been its exempting EHRs and others from the ACA’s medical device tax. However, by removing FDA’s jurisdiction, it would also exempt EHRs from AE reports. Repealing a tax is always popular. Preventing AE reports may make vendors happy, but clinicians, patients and the public may not be as sanguine.

The act’s first two sections declare that any software whose main purpose is administrative or financial won’t come under device reporting.

Subsection (c) is the heart of the act, which exempts:

Electronic patient records created, stored, transferred, or reviewed by health care professionals or individuals working under supervision of such professionals that functionally represent a medical chart, including patient history records,

Subsection (d) says that software that conveys lab or other test results are exempt.

Subsection (e) exempts any software that makes recommendations for patient care.

There are several problems with this language. The first is that while it goes to lengths to say what is not a device, it is silent about what is. Where is the line drawn? If an EHR includes workflow, as all do, is it exempt because it also has a chart function? The bill doesn’t say

Subsection (d) on lab gear is also distressing. Currently, most lab gear are FDA devices. Now, if your blood chemistry report is fouled by the lab’s equipment ends up harming you, it’s reportable. Under MEDTECH, it may not be.

Then there’s the question of who’s going to decide what’s in and what’s out? Is it the FDA or ONC, or both? Who knows Most important, the bill’s negative approach fails to account for those AEs, as ECRI puts it when: “Default values being used by mistake, or fields being prepopulated with erroneous data.”

Contradictory Terms

The act has a fascinating proviso in subsection (c):

…[P]rovided that software designed for use in maintaining such patient records is validated prior to marketing, consistent with the standards for software validation relied upon by the Secretary in reviewing premarket submissions for devices.

This language refers to information that device manufacturers file with HHS prior to marketing. Oddly, it implies that EHRs are medical devices under the FDA’s strictest purview, though the rest of the act says they are not. Go figure.

What’s It Mean?

The loud applause for the MEDTECH act coming from the EHR industry, is due to its letting vendors off the medical device hook. I think the industry should be careful about what it’s wishing for. Without effective reporting, adverse events will still occur, but without corrective action. In that case, everything will seem to go swimmingly. Vendors will be happy. Congress can claim to being responsive. All will be well.

However, this legislative penny in the fuse box will prove that keeping the lights on, regardless of consequences, isn’t the best policy. When something goes terribly wrong, but isn’t reported then, patients will pay a heavy price. Don’t be surprised when some member of Congress demands to know why the FDA didn’t catch it.

By

Adverse Event Reporting: What Is It?

Note: This was originally posted on: EMRandEHR.com
Eric Duncan’s Ebola death in Dallas was, to say the least, an adverse event (AE). Famously now, when he had a high fever, pronounced pain, etc., he went to Texas Health’s Presbyterian Hospital’s ER, and was sent home with antibiotics. Three days later much worse, he came back by ambulance.

In the aftermath of Duncan’s death, the hospital’s EHR, EPIC, came in for blame, though it was later cleared. Many questions have come from Duncan’s death including how our medical system handles such problems. Articles often use the term adverse event, but rarely mention reporting. I think it’s important to take a direct look at our adverse event reporting systems and where EHR and AEs are headed. This note looks at AE systems. The next looks at where EHRs fit in.

The FDA: Ground Zero for Adverse Event Reports

HHS’ Food and Drug Administration has prime, but not exclusive, jurisdiction over adverse reports breaking them into three classes:

  • Medicines
  • Medical Devices, and
  • Vaccines.

Four FDA systems cover these classes:

  • FAERS. This is FDA’s system for drug related adverse reports. It collects information for FDA’s post marketing for drug and biologic product surveillance. For example, if there’s a problem with Prozac, it’s reported here.
  • MAUDE. The Manufacturer and User Facility Device Experience reporting system. If an X-Ray machine malfunctions or lab equipment operates defectively, this is where the report goes.
  • VAERS. Vaccine adverse reports are collected here.
  • MEDSUN. This is voluntary, device reporting system gathers more detailed information than MAUD. It’s run by as a collaboration of the FDA and several hundred hospitals, clinics, etc. (Disclosure: My wife was MAUD project system developer.) MEDSUN captures details and incidents, such as close calls or events that may have had a potential for harm, but did not cause any. MEDSUN has two subsystems, HeartNet, which is for electrophysiology labs and KidNet for neonatal and pediatric ICUs.
DSC04388

MEDSUN Reporting Poster

State AV Reporting Systems

Several states require AV reporting in addition to FDA reports. Twenty-seven states and DC require AV reports, with varying coverage and reporting requirements. Some states, such as Pennsylvania, have an extensive, public system for reporting and analysis.

Patient Safety Organizations

Added to federal and state organizations are many patient safety organizations (PSOs) with an AV interest. Some are regional or state groups. Others, are national non profits, such as the ECR Institute.

The Safety Reporting Paradox

If you delve into an AV reporting systems, you’ll quickly see some institutions are more present than others. That doesn’t necessarily mean they are prone to bad events. In fact, these may be the most safety conscious who report more of their events than others. Moreover, high reporters often have policies that encourage AE reporting to find systemic problems without punitive consequences.

Many safety prevention systems work this way. Those in charge recognize it’s important to get all the facts out. They realize adopting a punitive approach drives behavior underground.

For example, the FAA has learned this the hard way. Recently on vacation, I met two air traffic controllers who contrasted the last Bush administration’s approach to now. Under Bush’s FAA errors were subject to public shaming. The result was that many systemic problems were hidden. Now, the FAA encourages reporting and separates individual behavior. The result is that incidents are more reported and more analyzed. If individual behavior is culpable, it’s addressed as needed.

In the next part, I’ll look at how EHRs fit into the current system and the congressional efforts to exempt them from reporting AEs, a move that I think is akin to putting pennies in a fuse box.

By

The Other Talk: EHRs and Advance Medical Directives

Note: This was originally posted on: EMRandEHR.com

The Other Talk: EHRs and Advance Medical Directives

Most of us who have adult children can remember that awkward talk we had about life’s origins. We thought, whew, that’s done. Alas, there’s yet another talk. This time it’s with those adult children and it’s about you.

This one’s covered in Tim Prosch’s and AARP’s book, The Other Talk. The talk, or more accurately the process is how you want to spend The Other Talkthe rest of your life. It’s about your money, where and how you’ll live and your medical preferences. It’s just as hard, if not harder, than the old talk because:

It’s hard to admit that you won’t be around forever and your independence may start to ebb away.

  • You don’t want to put your kids on the spot with difficult decisions.
  • Your children may be parents coping with their own problems. You don’t want to add to their burdens.
  • You’ve been a source of strength, often financial as well as emotional. That’s hard to give up.

Prosch and AARP want to make it easier on everyone to deal with these issues. He covers many topics, but for those of us who live in the EHR world one is of significant importance: Medical directives.

Prosch explains directives and simply says you should give them to your doctor. Easier said, etc. Today, that means not only your PCP, but also making sure that hospitalists etc., know what you want. While the Meaningful Use program helps a bit. It’s still going to take some doing.

Medical Directives and EHRs

EHR MU1 recognizes directives’ importance requiring that they be accounted for:

More than 50% of all unique patients 65 years old or older admitted to the eligible hospital’s or CAH’s inpatient department have an indication of an advance directive status recorded.

This means that the EHR has to have the directives. However, MU 1 only goes halfway to what’s needed. It’s what the EHR does with directives that’s unsaid.

If the EHR treats a directive as a miscellaneous document, odds are it won’t be known, let alone followed when needed.

To be used effectivelyPractice Fusion: Advanced Medical Directives, an EHR needs a specific place for directives and they should be readily available. For example, PracticeFusion recently added an advance directives function. That’s not always the case.

Googling for Directives

To see how about twenty popular EHRs treat directives, I did a Google site search, on the term directive. I got hits for a directives function only from four EHRs:

  • Athenahealthcare
  • Cerner
  • Meditech
  • PracticeFusion

All the others, Allscripts, Amazing Charts, eClinicalWorks, eMDs, McKesson, etc., were no shows. Some listed the MU1 requirement, but didn’t show any particular implementation.

Directives: More Honored in the Breech

This quick Google search shows that the EHR industry, with a few exceptions, doesn’t treat directives with the care they deserve. It should also serve as a personal warning.

If you already have directives or do have that talk with your family, you’ll need to give the directives to your PCP. However, you should also give your family copies and ask them to go over them with your caregivers.

Some day, EHRs may handle medical directives with care, but that day is still far off. Until then, a bit of old school is advisable.

By

I Want to Thank the Academy, Err, the Hospital CIO: EHR Hospital Market Share

Note: This was originally posted on: EMRandEHR.com.

We’re always interested in who’s up and who’s down. Whether it’s TV shows, Senate races, book sales or baseball stats, we want to know who’s up, who’s down and who’s going nowhere.

We’re big on trends, shares and who’s going where. The closer the race, the more avid the interest – My Nats would be sitting pretty if only the Braves weren’t so pesky. The EHR market place is no exception for interest, even if the numbers are a lot harder to follow than the National League East.

In my last foray into EMR market share, I looked at SK&A’s stats from their rolling survey of US medical practices.

Another company, Definitive Healthcare similarly tracks the hospital EHR marketplace. They’ve generously shared their findings with Healthcare Scene and I’ve used them here. Please note: Any errors, mistakes or other screw-ups with their numbers are mine alone. With that said, here’s what I’ve found.

How Many Divisions Does the Hospital Market Have?

Definitive divides the hospital market into several categories that can be daunting to follow. That’s not their making. It’s the nature of the market.

The major division that Definitive reports on is inpatient versus ambulatory systems. You might think that ambulatory systems are only for non hospital setting, but hospitals, of course, have many outpatients and use ambulatory EHR systems to serve them.

The Inpatient Marketplace

Among inpatient systems, EPIC leads with a 20 percent share shown in Tables I and II. The market is highly concentrated with EPIC, Cerner and Meditech commanding 54 percent. The remaining 46 percent scatters with no one breaking double digits.

Table I All Inpatient Hospitals EHR Vendor Market Shares

Table II All Inpatient EHR Shares

 The Ambulatory Hospital Marketplace

The picture for hospital ambulatory systems used is notably different. See Tables III and IV. While EPIC and Cerner vary slightly from their inpatient share, the other vendors shift all over the place. Allscripts barely registers 4 percent in inpatient, jumps to third place with 14 percent.

Siemens and HMS drop off the top ten being replaced by eClinicalWorks and NextGen. At 22 percent is the catchall, Other EHRs. This is up 8 percent from its inpatient 14 percent.

Table III All Ambulatory Hospitals

Table IV All Amb Hospitals

Inpatient EHRs: Health Systems and Independent Hospitals

Definitive also breaks down inpatient hospitals by health system hospitals v independents. Almost a majority of health systems, 47 percent, choose EPIC and Cerner. See Tables V and VI. Indeed, the top four vendors, EPIC, Cerner, Meditech and McKesson astoundingly have a 74 percent share. The other vendors are at 7 percent or less.

Table V Inpatient Healthcare Systems Hospitals

Independent hospitals differ a bit from this pattern. Non major vendors have 12 percent and open source Vista has 5 percent, but otherwise the pattern is similar.

Table VI Inpatient Independent Hospitals

Inpatient Hospitals by Size: Under and Over 100 Beds

Hospitals with 100 plus beds, no surprise, favor EPIC, Cerner and Meditech. These three have a monopolistic 64 percent. See Table VII.

Table VII Inpatient Hospitals with =>100 Beds

Small, Inpatient Hospital Systems: A More Competitive Market

Small hospitals are a different story. The top five vendors are bunched around 14 percent each. See Table VIII. The mix of vendors is starkly different. Meditech and Cerner lead with EPIC third. However, Epic drops nine percent from the prior group to 14 percent in this.

In the prior tables, the top three vendors have a market majority. In this group, 65 percent of the market belongs to the third through tenth vendors. You can see the difference in competition in Tables VIII and IX.

Table VIII Inpatient Hospitals =>100 Beds

Table IX Inpatient Hospitals <100 Beds

Hospital Ambulatory EHR Systems by Bed Size

The ambulatory market for hospitals with 100 plus beds is similar to the inpatient market. EPIC, Cerner and Allscripts have a 53 percent share.

The remaining share is split among several vendors, with eClinicalWorks, and athenahealth making an appearance. Significantly, Other EHRs ranked second.

Smaller hospitals’ ambulatory systems, as with smaller inpatient hospitals, show a competitive market. The category Other EHRs actually leads with a 21 percent share. Tables X and XI show the difference between these two markets.

Table X Ambulatory Systems =>100 BedsTable XI Ambulatory Systems <100 Beds

Market Shares: What’s the Conclusion?

In this and previous posts, I’ve looked at EHR vendor market shares sliced up in several ways. I’ve used what I consider reliable, independent data sources from SK&A and Definitive Healthcare. I used their information because they are careful to include all practices in their surveys not just those that bother to reply.

I also used them for the simple reason that they were freely available to us. There are other sources, such as KLAS, that produce market surveys, but they charge about $2,500 for their analysis. Moreover, they keep all but the most general findings behind their paywall.

What then is the message from all these numbers? It’s this: there is a competitive market, but it’s only robust among small practices. Those with three or less practioners have the most competitive market with eClinicalWorks in the lead. Within major segments, EPIC, Cerner and Meditech dominate. The non hospital market is more mixed, but EPIC, Cerner, etc., share increases as practice size grows.

For these larger practices, it’s monopolistic competition. If you’re looking for an EHR and you have ten or more docs, you can find any number of vendors. It’s most likely you’ll end up choosing among just a few big guys.

This reminds me of when we shopped for kitchen cabinets and counter tops. We were impressed with some dramatic possibilities. The sales rep, who we got to know well, laughed:

“When folks start out they focus on the avant garde. Then they realize they’re choosing for several years. Suddenly they get more conventional.”

If you come by our place, you’ll see our oak cabinets and white tile counter top. I think it goes that way with hospital execs choosing EHRs. They may toy with something different, but in the end, they’ll go with what they know. After all, no one every got fired for buying EPIC. Well, almost no one.

Next: Attribution and Market Share

If you still haven’t got your fill of market numbers, I have one more topic to explore. I’m interested in knowing how market share relates to MU attestations. That is, does a high market share guarantee a high attestation rate? The next post in this series will look at that.

If you have questions on market share, please post a comment or write me at: carl@ehrselector.com

By

Will Outsourcing VA Care Monkey Wrench VistA?

Note: This was originally posted on: EMRandEHR.com

The mess over the VA’s waiting times, with luck, will sort itself out with a revised management team and, perhaps, enough money to hire long needed staff.

One solution that’s pending in Congress is to let vets go outside the VA for care. From what I’ve read, most vets like the VA’s care and don’t want to change the main program, just fix it. However, that’s going to take time. The scandal has been around for a long time, at least since 2005 according to the VA’s Inspector General:

The issues identified in current allegations are not new. Since 2005, the VA Office of Inspector General (OIG) has issued 18 reports that identified, at both the national and local levels, deficiencies in scheduling resulting in lengthy waiting times and the negative impact on patient care. As required by the Inspector General Act of 1978, each of the reports listed was issued to the VA Secretary and the Congress and is publicly available on the VA OIG website.

Given the VA’s size and complexity as well as the need to recruit new staff and implement new procedures, permitting vets to use other resources has much appeal that crosses party lines. Two politically apart Senators, Bernie Sanders (I-VT) and John McCain (R-AZ)  started the change with their bill to allow outside care and more:

The Sanders-McCain legislation addresses the short-term problem of access to care by authorizing a two-year trial program that would allow veterans to seek private health care if they reside more than 40 miles from a VA facility or have been waiting more than 30 days for treatment. Long-term, the legislation authorizes the construction of 26 medical facilities in 18 states, and directs $500 million in unspent funds to hire more doctors and other health-care providers.

The House voted for outside providers, but killed any funding changes. The Senate passed the Sanders-McCain bill by a 93 to 2 vote. The next step is uncertain. One house could simply accept the other’s version, which is unlikely. The other alternative is a conference committee, which can draft its own version for both houses to vote on. Given the urgency, though, it’s probable that something will pass before long.

Wither VistA?

The fix, however, may unfix one of the VA’s strengths. It could create a medical record continuity problem separating vets from their records leaving VistA EHR, which tracks veterans healthcare, in the lurch.

How will vets’ records follow them to outside docs? Vets could download their records with Blue Button, but would local docs know what to do with them? When a vet’s encounter is over, how will the information get back to VistA, if at all.

Vets have a single, relatively well functioning medical record system. Here’s hoping the price of needed care doesn’t foul up what’s been working right.

By

EHR Product Market Shares Rankings: The Envelope Please!

Note: This was originally published at emrandehr.com.


In politics, it’s the horse race, that is, who’s in front and where’s the rest of the pack. We have our own EHR version, who’s got the biggest market share and where’s everyone else.

In politics, there’s no end of polling by candidates, parties, media and all stops in between. We aren’t so lucky. You can count the reliable EHR market share estimates on one hand and not need your thumb. Of those available, I’ve found SK&A’s to be the most comprehensive and reliable free option, though they do require a registration.

Leaders of the Pack

Table I shows the top 20 EHR vendors’ installed base for all US practitioners. Not surprisingly, Epic leads with about 11 percent. Table II shows the market’s concentration: the top seven have almost half the market.

Table I All practioners

The remaining 13 vendors have about a 20 percent market share. The remaining vendors, about 470 companies, have the remaining 30 percent. But don’t go away just yet. There’s more to the story.

Table II All Shares

Market Share by Practice Size

Market share by practice size refines the picture a bit more. For their analysis, SK&A divided practices into five classes shown in Table III. Each of these is examined in turn.

Table III Group Size

As you’ll see, the larger the number of practitioners in a class, the more concentrated the market becomes. However, the greatest number of practices is in the smaller classes. For example, SK&A reports that 80 percent of practices have 10 or less practitioners.

For example, both EPIC and eClinicalWorks have a ten percent market share. EPIC does this by having a large percent of practices with the highest number of practitioners.

 eClinicalWorks, on the other hand, achieves its share by selling to a many, smaller practices. As a result, you’ll see ECW’s market share drop as the numbers in a class increases, while EPIC’s share will go up.

Class 1 – 1 to 3 Practitioners

Table IV shows the top twenty vendors and again shows a heavy concentration in a few vendors. eClinicalWorks is the leading small practice EHR vendor with a 10 market share. The eight top vendors have half the market in this class.

Table IV 1 to 3 Practitioners

The other 12 top vendors have a 20 percent market share. The remaining 470 vendors split the remaining 30 percent.

Two EHR cloud vendors, Practice Fusion and athenahealth, have an 11 percent market share. While others offer hosted or private cloud products, these two are the sole cloud only solutions in the top 20.

This market segment shows less diversity than those before it. In this case, four vendors have almost half the market, Epic, Allscripts, eClinicalWorks and NextGen.

Class 2 – 4 to 10 Practitioners

The remaining 52 percent, Table V,  is spread among 16 vendors. Notably, athenahealth and Practice Fusion drop in this class to about 3 percent.

Table V 4 to 10 Practitioners

As the next classes show, the market tightens up considerably with a few vendors having greater and greater shares.After NextGen, the other 16 vendors have 30 percent of the market. This leaves all the remaining vendors with 23 percent of the market.

Class 3 – 11 to 25 Practitioners

In this class, Tables VI and VII, three vendors have a market majority: Epic, Allscripts and NextGen. The top seven vendors have over three-quarters of it. The concentration among is so great that three top 20 vendors, AdvancedMD, AmazingCharts and Office Ally are no shows.

Table VI 11 to 25 Practioners

Table VII 26 to 40 Practioner

Class 4 – 26 – 40 Practitioners

Table VIII shows the bunching of vendors in this practitioner class. Only about half of the major vendors had any significant share. All the remaining top 20 vendors lack any significant shares.

Table VIII 26 to 40 Practitioners

Epic’s dominance is even more pronounced in this final class as shown in Table IX. EPIC’s share 47.7 percent and GE has 11.9. Together, they have market share of about 70 percent.

Class 5 – 41 Practitioners and More

Epic’s dominance is even more pronounced in this final class as shown in Table IX. EPIC’s share 47.7 percent and GE has 11.9. Together, they have market share of about 70 percent.

Table IX 40 Plus Practioners The remaining five vendors have a 20 percent market share: Allscripts, Cerner, NextGen, McKesson. The other 400 plus vendors divide the remaining 10 percent.

There are some interesting changes in this class’ shares, Table X, compared to the previous classes. Cerner drops from second place with 12.5 percent to fourth place with 9.2 percent.

Table X 40+ Practitioners

MEDICTECH all but disappears dropping from 4.7 percent to 0.9. On the other hand, EPIC, GE, Allscripts, NextGen and Greenway increased their shares.

Source and Other Boring Details

The net has many EHR market share analyses, however SK&A’s stands out for several reasons. Most importantly is the active way they gather their statistics. They call every medical practice in the US every six months. This includes all hospitals, private or affiliated practices and urgent care clinics, etc. This approach means that few practices are left out and the answers gathered are on the same basis.

This differs substantially from studies that hang a question out and scoop in whatever they get. They don’t give all practices an equal chance to answer. They are flawed compared to those that actively contact practices or based on statistical samples.

Many other studies base their estimates on ONC’s MU attestations. In fact, most market studies I’ve seen cite ONC. The problem with ONC’s count is that it only includes those in the MU program. Those who don’t, perhaps 40 percent, are left out.

SK&A is not the only company that uses an active approach to determining market share. However, it is the only one I know of that actively surveys the market using that approach and publishes the results free. This is unusual.

I also want thank them for briefing me on their methodology. They did this with only the barest of descriptions of what I was up to.

Future Posts – Hospital and MU v Market Share

There are two other, related topics I’ll cover in future posts.

Hospital Practices

The first is a look at hospital based EHRs. Definitive Healthcare, similar to SK&A, actively surveys the in-patient market by calling practices. They have generously furnished their analysis to healthcarescene.com. Where SK&A breaks down its findings by class size, Dimension looks at hospitals by factors such as:

  • Bed size
  • Independent v affiliated hospitals, and
  • In-patient v ambulatory systems used in hospitals.

MU EHRs v Market Share

The last issue I want to look at is how the vendor rankings in MU’s attestations actually compare to those in this analysis. A preliminary look shows many differences.

By

fEMR Targets Pop Up Clinics’ Needs

Note: This was first published on emrandhipaa.com

Detroit’s Wayne State University students are pioneering fEMR, a special EMR for pop up clinics. These are transient clinics operating in under served areas with mass medical emergencies.

Beginning after Haiti’s devastating, 2010 earthquake, WSU’s undergraduate, medical students and doctors started staffing several pop ups. Operating with little or no electricity or other basic supports, these clinics often provide residents their only medical services.

Two volunteers, med student Erik Brown, and premed grad Sarah Draugelis, realized the need to create a basic medical record to aid their work and to print out for the patients. They looked at current EHRs, but they were far too complex, as Draugelis told Improvewsu.org,

We needed something that was fitted for high volume short-term clinics,” Draugelis explained. “We don’t have time to scroll and look at all the tabs in the EMR system. We need something very bare bones, very, very basic.” So, they looked into the EMR systems that already existed, but none of them fit the bill.

Last month, Brown and Draugelis told fEMR’s dramatic story on Live in the D TV show,

video platformvideo managementvideo solutionsvideo player

For help, the two turned to WSU Computer Science professor, Dr. Andrian Marcus, who recruited senior, Kevin Zurek, as technical lead.

fEMR is the result. Built using Play, a fast, light platform for web and mobile apps, fEMR incorporates a simple workflow of three steps: Triage, Medical and Pharmacy. Running on iPads, its tap and touch interface is designed for speed.

fEmr Triage Screen

fEmr Triage Screen

I contacted Zurek who gave me a login to their test site running on Chrome. It is, indeed, bare bones and fast. I created a patient, shown in the web shot above, and played with the package. Though a work in progress, it had no surprises, that is, no crashes, mysterious behavior, etc.

I asked Zurek what he sees as fEMR’s future? Are they going to take it commercial, etc.? He told me,

Our target audience generally consists of volunteers, so we have no concrete plans to commercialize fEMR as of right now. The purpose of fEMR is to bring continuity and increase efficiency in transient medical clinics while producing important data that can be used for research purposes.

In terms of the EMR system, we plan on delivering this to the end user in the most intuitive way possible, with as little training as possible. We have come to the conclusion that the best way to approach this is via an open environment that promotes collaboration across the board.

They need help to finish the work. Right now, they have two of six needed iPads. As befits the bootstraps nature of the project, they plan to raise funds with a car wash.

If you know some iPads that are a bit bored and looking for something more interesting to do, drop Zurek a line. He and the WSU team can keep them busy.

By

Has EHR Become a Bad Brand?

Note: This was first published on emrandhipaa.com

The other day, I had lunch at DC’s Soupergirl with the redoubtable Chuck Webster, workflow tool maven and evangelist. We talked a lot and discovered that both of us had a warm spot for the classic neighborhoods near Atlanta’s Piedmont Park. He as a transplant and I as a native.

More to this blog’s point, we discussed the state of EHRs and their numerous problems. Chuck wondered if EHR, per se, had become a bad brand? It’s a good question. Have we seen a once promising technology become, as has managed care, a discredited healthcare systems? It’s an easy case to make for a host of reasons, such as these:

Poor Usability. There are scads of EHRs in the marketplace, but few, if any, have a reputation as being user friendly. Whenever I first talk to an EHR user, I wait a few minutes while they vent about:

  • How they can’t put in or get out what they need to,
  • Their PCs being poorly located, inflexible or the wrong footprint,
  • Data that’s either missing, cut off or hard to find,
  • Logging in repeatedly,
  • Transcribing results from one system to put it in another,
  • Wading through piles of boilerplate, to get what they need etc., etc.
  • Having to cover PCs with sticky note workarounds.

As for patients, my friend Joe, a retired astrophysicist, is typical. He says when his doctor is on her EHR she doesn’t face him. She spends so much time keying, he feels like he’s talking to himself.

Now, it’s not completely fair to blame an EHR for how it’s implemented. The local systems folks get a lot of that blame. However, vendors really have failed to emphasize best practices for placing and using their systems.

Missing Workflows. EHRs, basically, are database systems with a dedicated front end for capturing and retrieving encounters and a back end for reporting. To carry out, their clinical role they have to be flexible enough to adapt to varying circumstances with a minimum of intervention.

For example, when you make an appointment for a colonoscopy, the system should schedule you and the doctor. It should then follow rules that automatically schedule the exam room, equipment, assign an anesthetist, and other necessary personnel, etc.

When you come in, it should bring up your history, give your doctor the right screens for your procedure, and have the correct post op material waiting. General business software workflow engines have done this sort of thing for years, but such functions elude many an EHR. EHRs without needed workflow abilities increase staff times and labor costs. They also mean users miss important opportunities and potential errors increase.

Data Sharing. Moving from paper to electronic records promised to end patient information isolation. Paper and faxed records can only be searched manually. However, with a structured electronic record, redundant entry would be reduced and information retrieval enhanced. Or so the argument went, but it hasn’t worked out that way.

While there are systems, such as the VA, Kaiser and various HIEs that fulfill much of the promise, it is still a potential rather than a reality for most of us. There are two basic reasons for this state of affairs: ONC’s mishandling of interchange requirements and one member of Congress’ misplaced suspicions.

ONC’s Role. ONC’s Meaningful Use program is meant to set basic EHR standards and promote data interchangeability.

When it comes to these goals, MU fell down from the start. MU1 could have been concise requiring an EHR to capture a patient’s demographics, vitals, chief complaint and meds.

Most importantly, MU could have made this information sharable by adopting one of HL7’s data exchange protocols. This would have given us a basic, national EHR system. Instead, MU focused on too many nice to have features, leaving data exchange way down the list.

ONC has tried to correct its data interchange a failing in MU2 to a degree, but it’s not there yet. Here’s what GAO, has to say about ONC’s efforts:

HHS, including CMS and ONC, developed and issued a strategy document in August 2013 that describes how it expects to advance electronic health information exchange. The strategy identifies principles intended to guide future actions to address the key challenges that providers and stakeholders have identified. However, the HHS strategy does not specify any such actions, how any actions should be prioritized, what milestones the actions need to achieve, or when these milestones need to be accomplished. GAO Report-14-242, March 24, 2014. Emphasis added.

Ron Paul. The other important obstacle to interchange came from Congress. When Congress passed HIPAA in 1996, it mandated that HHS develop a national, patient ID. However, in 1998 Ron Paul, (R-TX) deduced that since HHS wanted the ID system, it therefore wanted to put everyone’s medical records in a government database. He saw this as a threat to privacy. He got a rider added to HHS’s budget forbidding it to implement the ID system or even discuss one.

The ban’s remained in succeeding budgets. The rider has created a national medical data firewall for each of us, which hinders all of us. Paul’s gone from Congress, but Congress continues the ban. As Forbes’ Dan Munroe wrote about Paul’s ban:

The health data chaos we have today doesn’t allow for interoperability, portability or mobility. It’s why fax machines remain the ‘lingua franca” of U.S. healthcare. Every healthcare entity in the U.S. sees each patient, event and location as unique to them. For lack of a single identifier, there’s no easy or cost-effective way to coordinate patient care. Emphasis added.

While the lack of a patient ID is not EHRs fault, it noticeably reduces their ability to interchange information. State or other HIE’s are, in effect, workarounds for lack of a uniform ID. This situation adds to the perception of EHRs as unresponsive technology.

Onerous Agreements. As many an EHR buyer has found, vendors see EHRs as a sellers’ market. They use this to write onerous license agreements exempting their products from adhering to standards such as MU or from responsibility for costly errors or omissions.

These agreements not only limit liability, but often silence a buyer’s adverse comments. The effect is to cut buyers from any meaningful recourse. This shortsighted practice adds one more layer to the EHR industry’s image as unresponsive, self serving and defensive.

Whither the Brand?

The question then is are things so bad that EHR needs rebranding? If so, how should this be done by calling EHRs something else, advocating for a different technology, or yet another alternative?

For some brands, a new name along with some smart PR will do. That’s how Coca Cola reversed its New Coke fiasco. EHRs have a tougher problem. EHRs are not a one vendor product. They are a program class. Reforming EHR’s brand will take more than effective PR. It will take pervasive technical and policy changes.

Change From Where?

Change in a major technical field, as in public policy, requires either overcoming or going around inertia, habit, and complacency. EHRs are no exception. Here are some ways change could happen.

External Events. The most likely source of change is a crisis that brings public pressure on both the industry and government. There is nothing like a tragedy to grab public attention and move decision makers off the dime. I don’t want it to occur this way, but a life threatening or life taking event makes events go into fast forward and move issues from obscure to inevitable. Given EHRs many patient safety problems, this is all too likely an outcome.

ONC Initiative. ONC could step in and help right matters. For example, as I have advocated, ONC could run NIST’s usability protocols for all systems seeking MU certification. It could then publish the test results giving users a needed, common benchmark. This, in turn, could be a major push to get vendors to regard usability, etc., as an important feature.

ONC is not inclined to do this. Instead, it asks vendors to pick one of several versions of user centric technology. As Bennett Lauber, Chief Experience officer of The Usability People recently told HIEWatch:

“Usability certification for meaningful use really isn’t a test the way the rest of the certification process is. (Testers) go out and observe users, and report back to the certifiers,” Lauber reports. “There seem to be different sets of evaluation criteria because ONC has not really defined usability yet….” Emphasis Added.

Recently appointed ONC Coordinator, Dr. Karen Desalvo, unlike her predecessors, has been frank about changing ONC’s course. She’s revamped her advisory committee structure and spoken about going beyond meaningful use to big data.Notably, she understands the need for and the problems of interoperability. However, she’s not offered any changes in standards. ONC is in the best position to implement real standards, but for both political reasons; it’s unlikely to do so.

To chill things politically, vendors only have to find a few Congressmen who’ll, for a well placed contribution, will send ONC vendor drafted letters threatening its appropriation, committee reviews, etc. It can happen otherwise, but as Damon Runyon has said, “The race is not always to the swift, nor the battle to the strong, but that’s the way to bet.”

User Revolt. The most notable user push back to the status quo has involved unilateral EHR vendor agreements.

As Katie Bo Williams of Healthcare Drive (edited by Hospital EMR and EHR’s Anne Zieger) has notably described, major lawsuits are costing some vendors dearly. The industry, however, has yet to set buyer agreement standards that could aid its and EHRs’ reputation.

These lawsuits might chastise vendors, but users will need to become bolder if they want change. EHR vendors have an association to protect their interests. So do hospitals, physicians, practice managers, etc. Users are the one group that’s not represented.

You may belong to this or that product’s user group, but there is no one group that looks after EHR user’s interest. If there were a well organized and led EHR user group that lobbied for better usability, workflow tools and universal data exchange etc., then these issues would become more visible. More importantly, users would be able to demand a place at the table when ONC, etc., makes policy.

Those interested in patient safety, too, are taking some new directions. Recently, ECRI convened the Partnership for Promoting Health IT Patient Safety to promote changes, within “a non punitive environment,” that is, in a collaborative setting among vendors, practioners, safety organizations, etc. While the group has not issued any reports, it offers two hopeful signs.

The group’s advisory panel includes experts, such as, MIT’s Dr. Nancy Leveson, who works in aeronautic and ballistic missile safety systems. The other factor is that the group has consciously sought to give vendors a place where they see the impact their products have on patient safety without the threat of litigation. Whether the group can bring this off and influence the market remains to be seen.

Technical Fix. It’s possible users may decide to fix EHR’s problems themselves. For example, the University of Pittsburgh Medical Center  (UPMC) uses a combination of EPIC, Cerner and its own clinical systems. It wanted to pull patient information into one, comprehensive, easily used profile. To do this, the Center developed a new, tablet front end that overcomes a variety of common EHR problems.

Once a major actor, such as Pitt, shows there is a market, others will explore it. You’ll know it’s a real trend, when a major vendor buys a front end start up and brands it as its own.

Natural Turnover. Finally, John recently raised the question of EHRs’ future in What Software Will Replace EHR? He thinks that change will come organically as more technically robust software pushes out the old.

Slowly replacing current EHRs with new tools is the most likely path. However, a slow path may be the worst outcome. Slow turnover would give us a mixture of even more incompatible systems. This would make the XP installed base problem look simple.

The EHR brand reminds me of a politician with both high positives and negatives. It may be liked by many, however, it also has a lot of baggage. As with a candidate in that position, something will have to change those negatives or it will find itself just an also ran.

By

O’Reilly Studies Health IT: The Information Technology Fix

Note: This was first published on emrandhipaa.com

O’Reilly Media specializes in books, courses and online services in technical innovation. This week, it released a new, comprehensive study on IT in Healthcare: The Information Technology Fix for Health (PDF). It’s written by O’Reilly editor Andrew Oram, who frequently writes on healthcare IT’s trends and issues. Oram takes on four basic, health IT areas in this cogent review:

  • Devices, sensors, and patient monitoring
  • Using data: records, public data sets, and research
  • Coordinated care: teams and telehealth
  • Patient empowerment

In doing so, he brings a sound knowledge of health IT current technology and issues. He also brings a rare awareness that health IT often forgets its promise to combine modern tools with an intimate doctor patient relationship:

In earlier ages of medicine, we enjoyed a personal relationship with a doctor who knew everything about us and our families—but who couldn’t actually do much for us for lack of effective treatments. Beginning with the breakthroughs in manufacturing antibiotics and the mass vaccination programs of the mid-twentieth century, medicine has become increasingly effective but increasingly impersonal. Now we have medicines and machinery that would awe earlier generations, but we rarely develop the relationships that can help us overcome chronic conditions.

Health IT can restore the balance, allowing us to make better use of treatments while creating beneficial relationships. Ideally, health IT would bring the collective intelligence of the entire medical industry into the patient/clinician relationship and inform their decisions—but would do so in such a natural way that both patient and clinician would feel like it wasn’t there. P. 4-5.

Recommended reading.

Screen Shot 2014-04-03 at 12.32.30 PM

By

Reply to Dr. Jacob Reider on NIST Dissects Workflow: Is Anyone Biting?

Note: This was first published on emrandehr.com

One comment on my latest post, NIST Dissects Workflow: Is Anyone Biting?, deserves a more than casual reply.

Here’s the comment from Jacob Reider (Note: Dr. Reider is ONC’s Acting Principle Deputy National Coordinator and Chief Medical Officer. He has made major contributions to the HIT field and is one of its significant advocates.)

Carl, ONC’s UCD requirement references ISO 9241–11, ISO 13407, ISO 16982, NISTIR 7741, ISO/IEC 62366 and ISO 9241–210 as appropriate UCD processes.

We also require summative testing as defined in NISTIR 7742.

Might “Refuses to incorporate NIST recommendations” be a bit of an overstatement?

We solicited public comment in our proposed rule for 2015 certification and would welcome specific suggestions for how we can/should improve user experience of health IT products for efficiency and safety.

Dr. Reider, thank you for your comment – it certainly falls into the category of you never know who’s reading.

Let’stake a look at your last comment first, “Might ‘Refuses to incorporate NIST recommendations’ be a bit of an overstatement?”

Obviously, I don’t think so, but I am not alone.

I based my comment on ONC’s statement in its rule making that refers to NIST’s usability protocols. It says:

While valid and reliable usability measurements exist, including those specified in NISTIR 7804 “Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records,” (21) we are concerned that it would be inappropriate at this juncture for ONC to seek to measure EHR technology in this way.

Sounds like a rejection to me, however, don’t take my word. Here’s the AMA’s response to this decision. First, they demur and quote ONC:

We disagree with ONC’s assertion in the Version 2014 final rule that, “[w]hile valid and reliable usability measurements exist, including those specified in NISTIR 7804 ‘‘Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records,’’ we expressed that it would be inappropriate for ONC to seek to measure EHR technology in this way.”

It then says:

To the contrary, we believe that it is incumbent upon ONC to include more robust usability criteria in the certification process.  The incentive program has certainly spurred aggressive EHR uptake but has done so through an artificial and non-traditional marketplace.  As a consumer, the physician’s choice of products is limited not only by those EHRs that are certified but also by the constraint that all of these products are driven by federal criteria.  The AMA made several detailed recommendations for improving Version 2014 certification in our Stage 2 comment letter, which were not adopted, but still hold true, and we recommend ONC consider them for the next version.  Testimony of AMA’s Health IT Policy Committee’s Workgroups on Certification/Adoption and Implementation, July 23, 2013, pp. 5-6

I recognize that ONC says that it may consider the protocols in the future. Nevertheless, I think the plain English term rejected fits.

In the first part of his statement, Dr. Reider cites several ISO standards. With the exception of the Summative Testing, all of these have been referred to, but none have been adopted. Reference to a standard is not sufficient for its inclusion under the operation of the federal Administrative Procedure Act, which governs all federal agency rulemaking. In other words, these standards are important, but ONC simply calls them out for attention, nothing more.

I think two factors are at work in ONC’s reluctance to include the NIST usability protocols. The first is that the vendors are adamantly opposed to having them mandated. However, I believe there is a way around that objection.

As I have argued before, ONC could tell vendors that their products will be subject to a TURF based review of their product for compliance and that the results would be made public. That would give users a way to judge a product for suitability to their purpose on a uniform basis. Thus, users looking at the results could determine for themselves whether or not one or more non compliance was important to them, but at least they would have a common way to look at candidate EHRs, something they cannot do now , nor under ONC’s proposed approach.

The other factor is more complex and goes to the nature of ONC’s mission. ONC is both the advocate and the standards maker for HIT. In that, it is similar to the FAA, which is vested with both promoting and regulating US aviation.

It’s well established that the FAA’s dual role is a major problem. It’s hard to be a cheerleader for an industry and make it toe the line.

With the FAA, its dual mandate is exacerbated when the highly respected NTSB investigates an incident and makes recommendations. The FAA, acting as industry friend, often defers NTSB’s authoritative and reasonable recommendations to the public’s determent.

I believe that something similar is going on with ONC. NIST’s relationship to ONC is roughly analogous to that of the NTSB’s to the FAA.

NIST is not an investigative agency, but it is the federal government’s standards and operations authority. It isn’t infallible. However, ONC dismissing NIST’s usability protocols, in one word, inappropriate. It did this without explanation or analysis (at least none that they’ve shared). In my view, that’s really inappropriate.

ONC has a problem. It’s operating the way it was intended, but that’s not what patients and practioners need. To continue the aviation analogy, ONC needs to straighten up and fly right.

By

NIST Dissects Workflow: Is Anyone Biting?

Note: This was first published on emrandehr.com
Psst. Hey, Buddy, wanna see an EHR, visit’s workflow? Here it is, thanks to the National Institutes of Standards and Technology’s (NIST) new report, NISTIR 7988, Integrating Electronic Health Records into Clinical Workflow, etc.

Returning Patient Ambulatory Workflow NIST

What It Represents

NIST wants to make EHRs usable and useful. It first took aim at patient safety EHR functions that endangered, confused users or were error prone. To counter these, it developed and recommended EHR usability protocols.

Now, in an extensive report, it’s tackled EHR workflow to determine where problems occur. The result is a comprehensive work with significant findings and recommendations. The question is: Is anyone listening?

NIST’s Analytical Approach

NIST decided to create a typical workflow by interviewing knowledgeable physicians, who it calls Subject Matter Experts, SMEs. The physicians had different specialties and used different EHRs, though who they were, NIST doesn’t say.

From their discussions, NIST’s analysts created the above chart, NIST’s Figure 2. NIST’s authors recognize that actual workflows will vary based on setting, sequences, staffing, etc., but that it provides a useful way to look at these issues.

What They Did With It

Working with their physicians, NIST’s analysts broke down the workflow into three sections: before, during and after the visit. Then, they broke down, or decomposed, each of those sections, like opening nested Russian dolls. For example, they segmented the physician’s encounter, below, and once again, broke each down into its functions.

Returning Patient, Physician Encounter - NIST

What They Found

It was at this stage the analysts found significant variations among the EHRs used by their physicians,

[T]here appeared to be high variation in whether and how the EHR was used during this period, how extensive each of the activities typically were for each SME, different based upon the type of patient, how complex the patient was, context of how busy the day was, and other factors. NSTIR 7988, p 18.

Despite these differences, the physicians identified two issues that crossed their EHRs:

  • Working Diagnoses. The physicians wanted systems that let them create a working diagnosis and modify it as they worked until they made a final diagnosis. Similarly, they wanted to be able to back up and make changes as needed, something current systems make hard.
  • Multiple Diagnoses. Diagnoses usually involve multiple causes, not single factors. They wanted their EHRs to support this.

These types of issues aren’t new to those familiar with EHR problems. What’s new is NIST, as an independent, scientific organization, defining, cataloguing and explaining them and their consequences.

What They Recommended

From this work, NIST’s analysts developed extensive and persuasive recommendations, in three categories:

  • EHR Functions
  • System Settings, and
  • System Supports

EHR Functions

NIST’s recommends reducing practitioner workload, while increasing their options and supports. For example, they suggest:

  • Workload Projections. Give practitioners a way to see their patient workloads in advance, so they can plan their work more effectively
  • Notes to Self. Let users create reminder notes about upcoming visit issues or to highlight significant ,patient information. These would be analogous to their hand written notes they used to put on paper charts.
  • Single Page Summaries. Create single page labs summaries rather than making users plow through long reports for new information.
  • Single Page Discharge Summaries. Eliminate excessive boiler plate with more intelligent and useful discharge sheets.
  • Highlight Time Critical Information. Segregate time critical information. Often they get mixed in with other notices where they may be overlooked or hard to find.
  • Allow Time Pressure Overrides. When time is critical, EHRs should allow skipping certain functions.
  • System Settings

NIST recommendations echo the familiar litany of issues that characterize poor implementations:

  • Allow Patient Eye Contact. Exam room designs should put the doctor and patient in a comfortable, direct relationship with the computer as a support.
  • Login Simplification. Allow continuous logins or otherwise cut down on constant login and outs.

System Supports

The physicians recognized they often caused workflow bottlenecks. NIST recommended off loading work to medical assistants, nurse practitioners, physician assistants, etc.. For example, physician assistants could draft predicted orders for routine situations for the physician to review and approve.

Progress Note Frustrations

In the thorny area of clinical documentation, the report details physician frustration with their EHRs. All experienced excessive or missing options, click option hell, excessive output, puzzling terms, etc. These were compounded by time consuming system steps that did not aid in diagnosis or solving patient problems. The report discusses their attempts at improving documentation:

Several of the SMEs had attempted and then abandoned strategies to increase the efficiency of documentation. One SME reported that copying and pasting and “smart text” where typing commands generate auto-text had a “vigilance problem.” The issue was that it would be too easy to put the wrong or outdated information in or in the wrong place and not detect it, and then someone later, including himself, could act on it not realizing that it was incorrect.

One physician described an attempt to use automated speech recognition for dictation for a patient with scleritis, which is inflammation of the white of the eye. He stopped using the software when what was documented in the note was “squirrel actress.”

Another SME described that colleagues relied upon medical assistants to draft the note and then completed it, but they did not like that approach because it was too tempting to rely upon what was typed without reviewing it, and he felt the medical knowledge level was not high enough for this task.

One SME described a reluctance to use any scribe, including a medical student, because the risk would be too high of misunderstanding and thus not correctly documenting the historical information, diagnosis, and treatment plan. This was particularly problematic if the physician had information from prior visits, which contributed to these elements, which were not discussed in detail during the visit. NSTIR 7988, p. 28

Coding their diagnoses into progress notes also came in for criticism:

All SMEs described frustration with requirements to enter information into progress notes, …, which were applied to the notes in order to have sufficient justification to receive reimbursement for services. Although all of the SMEs acknowledged the central importance of receiving reimbursement in order to function as a business, this information was often not important for clinical needs. NSTIR 7988, p. 28

 

Role Based Progress Note

Unlike other areas of the report, the doctors could not agree on what to do, nor does NIST offer any specific cures for documentation problems. Instead, NIST recommends using a new, role based, progress note:

[T]he progress note for a primary care physician would have a different view from a specialist such as a urologist physician, who might not need to see all of the information displayed to the primary care physician. Similarly, the view of the note for primary care providers could differ from the view of a billing and coding specialist. … NSTIR 7988, p. 28

Will ONC Respond?

In this and its prior reports, NIST covers a lot of EHR issues making sensible recommendations that not only improve functionality, but more importantly improve patient safety. However, NIST’s recommendations are just that. It’s not a regulatory agency, nor is supposed to be one. Instead, its role is to work with industry and experts to develop usable, practical approaches to tough technical, often safety related, problems. To its credit, it’s done this in a vast number of fields from airplane cockpits, nuclear reactors, and atomic clocks to bullet proof vests.

However, its EHR actions have not gained any noticeable traction. If any EHR vendor has implemented NIST’s usability protocols, they haven’t said so. They are not alone.

Notably ONC, one of NIST’s major EHR partners, refuses to incorporate any of NIST’s usability recommendations. Instead, ONC requires vendors to implement User Centered Design, but does not define it, letting each vendor do that for themselves.

NIST has many answers to common EHR workflow and usability problems. The question is, who will bring them to bear?

By

An Eclectic Gathering of EHR Usability and Project Resources

Note: This was first published on emrandehr.com
Here are a few resources that I use to solve a variety of design, project management and other problems. Some, such as NIST’s protocols, are directly EHR related; others aren’t, but easily apply to EHR problems.

So here, as was once said, are a few of my favorite people and things:

  • Dan Bricklin. Hopper and Jobs are gone. Woz is a sage. Gates, Kapor and Norton long ago stopped being systems innovators in favor of being philanthropists. Bricklin, however, the electronic spreadsheet’s inventor, soldiers on. His personal site has much to offer, especially his video on interface development for different types of devices and users.
  • Donald Norman. If you only read one of Norman’s many works on usability, make it The Design of Everyday Things. When you do, you’ll find one of the most cogent, funny and thoughtful studies of user centered design. From his account of slide projectors from hell, to post office doors that trap the unwary, to the best ways to arrange light switches, Norman has good advice for all of us. I first read this twenty years ago, but the advice still resonates. He’s recently revised it and added a free on-line course. After Norman, you won’t look at doors, appliances, much less screens the same way again.
  • Jakob Nielsen. There are people who think if you know Nielsen’s usability approach, you need little else. Then, there are those who think if you know Nielsen’s approach, all hope is lost. No one has a monopoly on good interface design, but Nielsen’s site is a place to stop for tons of notable examples.
  • NIST Protocols. NIST works with the private sector to solve major, operational problems. After Three Mile Island close call NIST redesigned all US nuclear power plants’ control rooms. Recently, they’ve developed EHR usability standards. These are the best, most comprehensive treatment of what not to do. You’ll find them in an appendix in their publication, NISTIR 7804.
  • ONC Repository. Most those in the EHR field know ONC, for better or worse due to its Meaningful Use standards. There’s a lot more. Buried on ONC’s site is its Implementation Resources. The repository has dozens of videos, guides, white papers, toolkits and templates all centered on improving EHR selection, implementation and use.
  • Ross Koppel. Koppel is a grouch. He grouches about the dozens different ways EHRs record simple things, such as, blood pressure. Writing often in JAMA, he notes how health IT systems spawn workarounds, confusion and give users choices that are false, misleading or illogical. In short, he’s produced a treasure trove of frightening observations, embarrassing questions and pointed observations, but his bête noire findings also include correctives. All of this is written in a careful, thoughtful style that makes the subject compelling and chilling.
  • Tom Demarco. Demarco of the Atlantic System Guild has produced a wealth of insightful books, lectures and articles on project management. In the 60s, DeMarco asked himself, if a civil engineer can build a bridge from requirements to operation, why can’t we do the same thing with software. His first take was Structured Analysis and System Specification. It’s still in print and full of practical advice and approaches for project managers. Other works include Peopleware: Productive Projects and Teams, where he takes the odd position that you should treat your staff like people and help them be productive. I especially love his The Deadline: A Novel About Project Management in which the main character is kidnapped and forced to manage a project under threat of death. It’s a comedy.

Interested in EHR usability? Join my LinkedIn group: EHRUsability.

By

Drop In Clinics: Another EHR Quandary

Note: This was first published on emrandehr.com

If you go to a walk in health clinic, you’re in good company. These clinics and their users are growing rapidly. So, too, is their using EHRs to document your stay. That EHR use is both good and bad news.

 Clinic Types

There are two basic types of these no appointment, walk in clinics: Retail Health and Urgent Care:

  • Retail Health. These treat minor problems or do basic prevention that usually doesn’t require a physician visit. For example, they give flu shots, treat colds, ear infections, and strep throat, etc. The clinics are often one person operations staffed by a nurse practitioner. You can find them in stand alone settings, but more frequently now they are in major, retail chains such as Target, Wal-Mart, CVS, etc. In addition to their location accessibility, these clinics usually have evenings and weekend hours.
  • Urgent Care Clinics. These perform all the services of retail clinics, and also have extended hours. Importantly they add physician services. For example, they will treat burns, sprains, or run basic lab tests. These clinics usually are part of a clinical chain or may be associated with a local hospital. Unlike retail health clinics, they generally are in their own store fronts.

While their services and settings differ, both accept health insurance. With the projected growth of the insured population under the ACA, their managers are expanding their networks.

Clinic EHR to PCP EHR Problem

Unlike practices and hospitals that have undergone, often painful, transitions from paper to EHRs, these clinics, skipped that phase and have, by and large, used EHRs from the start.

EHRs give them a major advantage. If you visit Mini-Doc Clinic in Chamblee, Georgia and then go to one in Hyattsville, Maryland, the Maryland clinic can see or electronically get your Georgia record. This eliminates redundancy and gives you an incentive to stay with a service that knows you.

If you only go to Min-Doc for care, then all your information is in one place. However, if you use the clinic and see you regular doctor too, updating your records is no small issue. Coordination of medical records is difficult enough when practices are networked or in a HIE. In the case of a clinic, especially one that you saw away from home, interface problems can compound.

With luck, the clinic you saw on vacation may use the same EHR as your doctor. For example, CVS’ Minute Clinic uses Epic. However, your clinic may use an EHR tailored to walk ins. Examples of these clinic oriented, tablet, touch optimized EHRs are:

Your physician may not have the technical ability to read the clinic’s record. Getting a hospital to import the clinic’s data would require overcoming bureaucratic, cost and systems problems for what might be a one time occurence. Odds are the clinic will fax your records to your doctor where they will be scanned or keyed in, if at all.

This is not a hypothetical issue, but one that clinic corporate execs, patient advocates and physicians are concerned about. There is no easy solution in sight.

Recently, on point, NPR’s Diane Rehm show had a good discussion of the clinic phenomena, and included the clinic to PCP EHR record issue. You can hear it on podcast. Her guests were:

  • Susan Dentzer. Senior Policy Adviser, The Robert Wood Johnson Foundation and on-air analyst on health issues, PBS NewsHour.
  • Dr. Nancy Gagliano. Chief Medical Officer, CVS MinuteClinic.
  • Dr. Robert Wergin. Family Physician, Milford, Neb., and President-elect, American Academy of Family Physicians, and
  • Vaughn Kauffman. Principal, PwC Health Industries.

All the actors in this issue know that the best outcome would be transparent interoperability. However, that goal is more honored in the breach, etc., for EHRs in general. The issue of clinic to PCP EHR is only at a beginning and its future is unknown.

By

Where the Health IT & EHR Jobs Are: Take Two

Note: This was also a guest publication on emrandehr.com

There’s Epic and Then There’s Everybody Else

In the first EHR job review, I looked at the demand for EHR/HIT certifications from organizations such as AHIMA. In this review, I wanted to find the most in demand product certifications. That is, if you’re thinking about being certified in a product, which ones have the most openings? There are two short answers:

  • It’s complicated, and
  • Epic

Where to Look?
Finding openings in the first review was straightforward. In this case, compiling a list of product certifications was more complex.

To start, I assumed that the bigger a company’s market share, the more likely there would be openings. This led to asking, what were the vendor shares? For an answer, I used SK&A’s recent report. They continuously call practitioners about a host of issues. Most other studies are either self selecting web polls or use ONC’s attribution stats. The latter is a hard count, but doesn’t take into account those who don’t participate in MU. In a subsequent post, I’ll cover SK&A’s report and market shares in more depth.

Based on SK&A’s report, here’s the market share for the top 20. Among these, I looked for product certifications for the top dozen, which had a least 2.0 percent of the market.

Table I
EHR Market Share by Practioner Site Size
SK&A – January 2014

No

Vendor

   %

No

Vendor

   %

1

 Epic Systems Corporation

10.8

12

 MedPlus, A Quest Diagnostics Company

1.9

2

 eClinicalWorks

10.0

13

 eMDs, Inc.

1.7

3

 Allscripts

9.5

14

MEDITECH, Inc.

1.7

4

 Practice Fusion

6.4

15

 Sage Software

1.2

5

 NextGen Healthcare

5.7

16

Office Ally

1.2

6

 General Electric Healthcare IT

3.7

17

Community Computer Service Inc.

1.1

7

 Cerner Corporation

3.5

18

 BioMedix Vascular Solutions

1.0

8

 McKesson Provider Technologies

3.4

19

 NexTech Systems, Inc.

0.9

9

 athenahealth, Inc

2.8

20

AdvancedMD 1

0.9

10

 AmazingCharts.com, Inc.

2.5

21

 All Other Vendors (471)

28

11

 Greenway Medical Technologies, Inc.

2.0

 

 

Search Issues

In the prior review, it was simple to find CCA, CPHIMS openings, etc. Product certifications, as a rule, don’t have unique names and may be referred to in many ways. Typical variations for NextGen, etc., are:

  • Certified NextGen professional,
  • NextGen certified,
  • NextGen professional certification, etc.

In addition to these identification issues, there is also the issue of specialties. For example, Epic has about 40 apps from ADT (Inpatient and Outpatient Admission-Discharge-Transfer Application) to Wisdom (Dental Application).

Due to this complexity, and being interested in the relative demand for product certifications, I developed this search protocol, which seems to yield good results:

  • Source. As before, I looked for jobs posted on HealthcareITCentral.com in the last 30 days.
  • Limits. Only look for major product names, that is, not their product varieties.
  • Terms. For each product, I searched for three phrases that varied the product name and the word certification.

Here’s how, for example, here is how I searched for Allscripts’ certifications:

  • Allscripts certified
  • Allscripts certification, and
  • Certified Allscripts

As a check, I also did a Google search for Allscripts and certification to see if I missed a substantial number of openings.

This approach yielded, I believe, a representative group of openings, but it’s not all encompassing. For example, some job ads combine product names. An ad might say Allscripts/Epic certification, but the search engine won’t find Allscripts.

Searching for the words Allscripts and certification will capture more certification openings, but it also will bring up a slew of unrelated others.

The best way, then, to find these openings would be to search for the company name and certification, etc., within so many words of each other. This is called a proximity search. Many text search engines do proximity searches, but I don’t know of a job search engine that does.

Product Certification Openings

With that said, Table I shows the 134 openings I found among the top ten EHRs with 2 percent or more of the market.  This is quite low compared to the general demand for persons with Cerner, NextGen experience. Of the 134, Epic with 90 percent dominates. Only NextGen, with 11 has any other significant demand.

Table II
Product Certification Openings

Vendor

Openings

Epic

120

NextGen

11

Cerner

2

Allscripts

1

Total

134

Chart I shows the states with significant openings. It also shows how  a state’s openings rank compares to its population ranking:

  • Red Columns. Openings per state.
  • Purple Columns. These show how a state’s jobs rank compares to its population share. For example, if a state’s job rank is plus four then its jobs are four levels above its population rank. Conversely, if a state is minus four, its share is four less than its population rank.

It’s no surprise that the states with the largest populations have the most jobs. California leads with 36 openings. There are notable exceptions, such as Colorado, whose openings far outrank its population rank.

To Certify or Not To Certify

I was surprised that several products, such as eClinicalWorks, had no demand. There’s a good reason. From what I later discovered, eClinicalWorks, among others, doesn’t certify users of their products. Indeed, I found it is difficult to know which products have certification programs. Even if they do, it’s not easy to find details. For example, I’ve called and written Epic to find the details of its programs, but so far no response.

As a result, I’ve decided to look at the vendor certification program issue. I want to find out from vendors why they do or do not have programs, their market targets and their level of participation.

The lesson from this review is simple, if you have an Epic certification and live in California, you have good odds of finding a job match. If you are looking to become certified in a product, Epic would appear to be your best shot. However, that may not be the case.

Product specific certification programs are odd beasts. Much depends not only on your product experience, but also on the product vendor’s attitude toward you. Some vendors may have an open door to those who want to learn the product. Others, such as Epic, insist that you be part of an active Epic practice and they do all the training at their Verona, WI headquarters. There is no easy or accessible way to know the ground rules unless you are already using or have used the product.

If you are already familiar with a product, you may find that using social media and personal contacts are the best path to new work rather than setting out to be certified in another product.

By

Where the Jobs Are: Demand for EHR/HIT Certifications

See: 2015 Where the Jobs Are Update.

Note: This was also a guest publication on emrandehr.com

There are dozens of EHR/HIT certification program and counting. A few years ago, I got a CPHIMS. I did it in hopes it would open some work doors. I thought it was useful, well developed and administered, etc., but going full time running the EHRSelector.com took me in a different direction. Still, I’ve wondered which certification programs offer the most opportunity and where are they located?

With help from John’s newly acquired Healthcare IT Central job board, I found answers to these questions. HealthcareITCentral has one of the largest, if not the largest collection of HIT positions. Using its advanced search, I looked for jobs, in the last 30, days that required specific certifications.

A few caveats about this review:

  • Each certification counts as one position. For example, if one job posting listed ComTIA, CPHIMS and CPEHR, I counted it as three jobs, one for each certification.
  • General certifications only. For practical reasons this report only covers general certifications that have a one word abbreviation. Finding other certifications, such as eClinicalWorks Certified, etc., requires searching for phrases, which HealthcareITCentral currently doesn’t support (or John needs to teach me how to do). No doubt Epic certification and Cerner certification would be high on this list if it was included.
  • Dynamics. The results I found for these certifications are a snapshot. The job market and the openings that HealthcareITCentral lists constantly change. What is true now, could change in a moment. However, I believe this can give you a good idea of the relative demand that exists.

Certifications Reviewed

Table I lists the certifications and for which I found at least one opening.

Table I

Certifications With Open Positions

1

CCA

9

CHTS

2

CCDP

10

CompTIA

3

CCS

11

CPEHR

4

CCS-P

12

CPHIMS

5

CEMP

13

CPHIT

6

CHDA

14

CPORA

7

CHPS

15

RHIA

8

CHSP

16

RHIT

 

Table II, lists the certifications that had no openings in the last 30 days. I also did a quick check to see if any of these had any jobs listed at all. It appears that there were no open positions for these certifications, though as I note above matters can quickly change.

Table II

Certifications Without Open Positions

1

CAHIMS

8

CMUP

2

CEOP

9

CPCIP

3

CHTP

10

CPHIT

4

CHTS

11

CPHP

5

CHTSP

12

CPORA

6

CICP

13

HWCP

7

CIPCP

Certification Demand

I found that the system listed 1,500 or so positions in the past month. See Chart I. Of those, 440 or 30 percent mentioned one of these certifications.

Of all the certifications, AHIMA’s were most in demand. AHIMA’s prominence among the certifications reviewed is remarkable. It’s three programs account for two thirds of the certification positions.

Its RHIA (Registered Health Information Administrator) was mentioned 101 times. RHIA accounted for about 22 percent of the openings with RHIT (Registered Health Information Technician) slightly less at 94.

RHIA’s designed to show a range of managerial skills, rather than in depth technical ability. If you consider certifications proof of technical acumen, then the strong RHIA demand is a bit counter intuitive.

Where the RHIA has a broad scope, the close second, RHIT, is more narrowly focused on EHRs and their integrity.

In third place, but still with a substantial demand is CCS (Certified Coding Specialist), which as the name implies focuses on a specific ability.

Check out the top 5 certification job categories on Healthcare IT Central:
RHIT Jobs
RHIA Jobs
CCS Jobs
CompTIA Jobs
CCA Jobs

Certification Demand by Location

After looking at certification demand, I looked at demand by location. To do this I merged all the certification job openings into a single list. That is, I added those for RHIA, RHIT, etc., and then eliminated duplicates. This reduced the total from about 390 to 280.

The next step was to rank the states by their job numbers. Chart II for the top ten state openings shows this information two ways:

  • Blue Columns. Openings per state.
  • Green Columns. These show how a state’s jobs rank compared to its population share. For example, if a state is plus four then its jobs rank four levels above its population rank. Conversely, if a state is minus four, its share is four less than its population rank.

As you might expect, the states with the largest populations have the most jobs. California leads with 36 openings. However, there are some notable exceptions, such as Maryland.

Maryland has 21 jobs openings. This puts it fourth between Texas and New York. It is 15 ranks above where its population ranks it. Illinois, on the other hand has nine jobs. This puts it four ranks below its population standing.

 Chart II, Openings by State

Certifications are a response to the demand for persons with demonstrated skills. The question is whether a particular one will reward your time, cost and effort with something that is marketable. Demand alone can’t make that choice for you. Personal satisfaction can’t be discounted as a factor in any decision. I hope this short study may help you find the best fit for you.

By

Appointment Type’s the Headwaters of Workflow

It’s a rare EHR that doesn’t include scheduling an appointment’s time and purpose. Usually, there’s a line for the patient, which doctor and an appointment type. Patient and doctor are straight forward, but practices may not take advantage of what appointment type can do for them.

Even having meaningful types can be difficult. One practice I worked with just wanted minutes as appointment types, 15, 30, etc. That took a while to work through, but we finally settled on Initial, Pre Op, etc., which made tracking their work a little more meaningful.

Many EHRs leave the subject at having categories or adding insurance requirements. Other EHRs do more and can save a lot of time and work. Rather than seeing appointment type as a handy pigeonhole for patient types, these see appointment type in a critical workflow role of reserving resources for an encounter.

For example, if you schedule a patient’s annual physical, you’ll need a room and someone to do vitals, weight, etc., and an EKG. If you’re a male doctor with a female patient, you’ll want to have a woman staffer scheduled for part of the exam, too.

Rather than schedule these ad hoc, some systems allow you to define the resources needed for the appointment type and schedule them as needed.

Greenway’s PrimeSuite, for example, does this. Here’s how it sets up a new appointment type:

  • Click the + sign under the appointment type tab to add the new appointment type
  • Once you click on the + sign, enter the appointment type in the yellow box
  • To the right of the appointment type name, click the drop down and pick the duration of the appointment type
  • Enter the abbreviation of the appointment type (this will appear on the schedule screen)
  • In box #2 – Enter the patient instructions for this appointment type. This is a friendly reminder to your staff as to what they need to instruct the patient to bring or do.
  • In box #3 – Pick the color of the appointment which will appear on the schedule screen
  • In box #4 – Select and move to the right which resource/provider/room can see this appointment type
  • In box #5 – Select the visit type – category as to which superbill you will want to pull for this appointment type
  • In box #6 – Enter
  •  an alternative appointment type that can be printed on confirmations for the patients. This can be the same as box #1, which is your appointment type
  • Click the Save disc at the top
  • Repeat steps until all of your appointment types are entered into the system

Greenways Appointment Type
Greenway’s PrimeSuite Appointment Type Definition Screen

Greenway’s Box No. 4 lets the user specify the resources that go with this appointment type. The user can assign personnel, equipment, rooms, etc. When selected the system checks for availability and reserves them for the needed times

Many practices will be shopping for a new EHR in the coming year. Their shopping lists would do well to include a robust appointment type. Of course, I encourage anyone who’s in the EHR market to use our free resource, EHRSelector.com. The Selector’s Practice Management category has these two appointment type features:

  • PM50 (895) Appointment Type can reserve resources, for example, room, equipment.
  • PM51 (896) Appointment Type can schedule supporting personnel, such as technicians, aides etc.

By

Defining EHR Usability Isn’t for the Timid

Note: This was also a guest publication on emrandehr.com

Sometimes it seems that EHRs and usability are like Earth and Mars. Their orbits get relatively close, but they’re never going to occupy the same place and time.

Of course, the two we’re occupied with aren’t cosmic equals. EHRs are specific systems, while usability is, at best, a concept with various definitions. In fact, the closer you get to a definition of usability the less focused it becomes. My late brother used to call things like that, “Far aways.” “The farther away you get the better they look.”

Indeed, most definitions of usability say it’s something that’s useful. Ugh. So, is there any way to bring some clarity to its definition, so it has greater precision?

Doing so, I think, requires not only defining what usability is, but also tackling when it’s not present what’s wrong.

Usability: A Different Definition Approach

Most definitions of usability I’ve seen push the issue off onto use or useful. That is, usability is defined as something that is useable. This isn’t far from using a word to define itself, which was a grammar school no no. It also fails to involve the user’s expectation. I would define it this way:

Usability is the ability of a system to supply a desired result with the minimum necessary information, conditions or steps.

This definition hinges on a user getting what they want expeditiously. Simply put, usability means no unneeded fuss or feathers. As I look at it, usability is to systems what parsimony is to logic. In logic, the simplest explanation that explains the occurrence is the best. Similarly, the most usable system is the one that requires the least effort to supply the correct response.

User Hostile Systems

If I left matters at this juncture, however, I wouldn’t have addressed a major related issue. When a system is user hostile, just where has it gone wrong. Each of us has experienced or heard these tales. You make a simple request and wind up in wilderness of documentation or your options are have everything but what you want.

These are negative examples of usability. It is, however, not enough to just stamp them as such and move on. It’s also important to say exactly where usability fails. To get a handle on these issues, I divide them into three classes:

Class One: Bug. Generally, a computer or software bug is anything that caused a wrong or unexpected response. I take a narrower view. To me, a bug represents a properly designed system that’s incorrectly implemented. That is, the program code fails to carry out the system designer’s intent. For example, you click Print and the system emails your Aunt Edna.

Class Two: Design Failure. In these, the code is OK, but the requirements failed. The classic refrain for these is, “ Yes, that‘s what I asked for, but it isn’t what I wanted.” Fixing these, unlike bugs, requires correcting the requirements and conforming the code.

Class Three: Missing Requirement. Sherlock Holmes in the Silver Blaze mystery had this to say about EHR usability:

“Is there any point to which you would wish to draw my attention?”
“To the curious incident of the dog in the night-time.”
“The dog did nothing in the night-time.”
“That was the curious incident,” remarked Sherlock Holmes.

Nothing is less usable than something that doesn’t exist. It’s not a matter of getting wrong. It’s a matter of not getting it at all.

What makes this a difficult category to apply is the issue of user need. What some users think is fundamental, others may regard as a frill or not necessary at all. Usability, therefore, hinges on neither design nor programming but on policy. However, if policy deems the function important, then its omission is far more serious than the other two categories.

An example. I use a large practice associated with a local medical school. It uses Jardogs’ Followmyhealth (FMH) web portal. It conveniently combines PHR, email and scheduling. I especially like being able to email my PCP. Recently, however, I ran into a class three problem.

FMH lists my PCP and any other of my providers. My PCP suggested I see a specialist for a problem. I went to FMH to find a list of specialists and phone numbers. I got nowhere. I could remove a provider, but not find a new one. I searched FMH’s knowledge base for provider and got 40 hits, but nothing on finding one. I then went through the FMH Patient Guide again without luck. Frustrated, I left the system and went to the practice’s public web site. It had the list. I found the department and number I wanted. Once I got set up, the new provider appeared in FMH.

Wondering if I had missed something, I called support with the problem. The support rep spent several minutes, came back, and confirmed that it could not be done, which surprised him. He agreed they should at least have a link in FMH to search for providers. Whether FMH adds it, of course, is a policy question.

%d bloggers like this: