Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

Could Clinicians Create Better HIE Tools?

The following is a guest blog post by Andy Oram.His post reminds me of when I asked “Is Full Healthcare Interoperability a Pipe Dream?

A tense and flustered discussion took place on Monday, August 11 during a routine meeting of the HIT Standards Committee Implementation Workgroup, a subcommittee set up by the Office of the National Coordinator (ONC), which takes responsibility for U.S. government efforts to support new IT initiatives in the health care field. The subject of their uncomfortable phone call was the interoperability of electronic health records (EHRs), the leading issue of health IT. A number of “user experience” reports from the field revealed that the situation is not good.

We have to look at the depth of the problem before hoping to shed light on a solution.

An interoperability showcase literally takes the center of the major health IT conference each year, HIMSS. When I have attended, they physically arranged their sessions around a large pavilion filled with booths and computer screens. But the material on display at the showcase is not the whiz-bang features and glossy displays found at most IT coventions (those appear on the exhibition floor at HIMSS), but just demonstrations of document exchange among EHR vendors.

The hoopla over interoperability at HIMSS suggests its importance to the health care industry. The ability to share coordination of care documents is the focus of current government incentives (Meaningful Use), anchoring Stage 2 and destined to be even more important (if Meaningful Use lasts) in Stage 3.

And for good reason: every time we see a specialist, or our parent moves from a hospital to a rehab facility, or our doctor even moves to another practice (an event that recently threw my wife’s medical records into exasperating limbo), we need record exchange. If we ever expect to track epidemics better or run analytics that can lower health case costs, interoperability will matter even more.

But take a look at extensive testing done by a team for the Journal of the American Medical Informatics Association, recently summarized in a posting by health IT expert Brian Ahier. When they dug into the documents being exchanged, researchers found that many vendors inserted the wrong codes for diagnoses or drugs, placed results in the wrong fields (leaving them inaccessible to recipients), and failed to include relevant data. You don’t have to be an XML programmer or standards expert to get the gist from a list of sample errors included with the study.

And that list covers only the problems found in the 19 organizations who showed enough politeness and concern for the public interest to submit samples–what about the many who ignored the researchers’ request?

A slightly different list of complaints came up at the HIT Standards Committee Implementation Workgroup meeting, although along similar lines. The participants in the call were concerned with errors, but also pointed out the woeful inadequacy of the EHR implementations in representing the complexities and variety of patient care. Some called for changes I find of questionable ethics (such as the ability to exclude certain information from the data exchange while leaving it in the doctor’s records) and complained that the documents exchanged were not easy for patients to read, a goal that was not part of the original requirements.

However, it’s worth pointing out that documents exchange would fall far short of true coordinated care, even if everything worked as the standards called for. Continuity of care documents, the most common format in current health information exchange, have only a superficial sliver of diagnoses, treatments, and other immediate concerns, but do not have space for patient histories. Data that patients can now collect, either through fitness devices or self-reporting, has no place to be recorded. This is why many health reformers call for adopting an entire new standard, FHIR, a suggestion recognized by the ONC as valid but postponed indefinitely because it’s such a big change. The failure to adopt current formats seems to become the justification for keeping on the same path.

Let’s take a step back. After all those standards, all those certifications, all those interoperability showcases, why does document exchange still fail?

The JAMIA article indicated that failure can be widely spread around. There are rarely villains in health care, only people pursuing business as usual when that is insufficient. Thus:

  • The Consolidated CDA standard itself could have been more precisely defined, indicating what to do for instance when values are missing from the record.

  • Certification tests can look deeper into documents, testing for instance that codes are recorded correctly. Although I don’t know why the interoperability showcase results don’t translate into real-world success, I would find it quite believable that vendors might focus on superficial goals (such as using the Direct protocols to exchange data) without determining whether that data is actually usable.

  • Meaningful Use requirements (already hundreds of pages long) could specify more details. One caller in the HIT Standards Committee session mentioned medication reconciliation as one such area.

The HIT Standards Committee agonized over whether to pursue broad goals, necessarily at a slow pace, or to seek a few achievable improvements in the process right away. In either case, what we have to look forward to is more meetings of committees, longer and more mind-numbing documents, heavier and heavier tests–infrastructure galore.

Meanwhile, the structure facilitating all this bureaucracy is crumbling. Many criticisms of Meaningful Use Stage 2 have been publicly aired–some during the HIT Standards Committee call–and Stage 3 now looks like a faint hope. Some journalists predict a doctor’s revolt. Instead of continuing on a path hated by everybody, including the people laying it out, maybe we need a new approach.

Software developers over the past couple decades have adopted a range of ways to involve the users of software in its design. Sometimes called agile or lean methodologies, these strategies roll out prototypes and even production systems for realistic testing. The strategies call for a whole retooling of the software development process, a change that would not come easily to slow-moving proprietary companies such as those dominating the EHR industry. But how would agile programming look in health care?

Instead of bringing a doctor in from time to time to explain what a clinical workflow looks like or to approve the screens put up by a product, clinicians would be actively designing the screens and the transitions between them as they work. They would discover what needs to be in front of a resident’s eyes as she enters the intensive care ward and what needs to be conveyed to the nurses’ station when an alarm goes off sixty feet away.

Clinicians can ensure that the information transferred is complete and holds value. They would not tolerate, as the products tested by the JAMIA team do, a document that reports a medication without including its dose, timing, and route of administration.

Not being software experts (for the most part), doctors can’t be expected to anticipate all problems, such as changes of data versions. They still need to work closely with standards experts and programmers.

It also should be mentioned that agile methods include rigorous testing, sometimes to the extent that programmers write tests before writing the code they are testing. So the process is by no means lax about programming errors and patient safety.

Finally, modern software teams maintain databases–often open to the users and even the general public–of reported errors. The health care field needs this kind of transparency. Clinicians need to be warned of possible problems with a software module.

What we’re talking about here is a design that creates a product intimately congruent with each site’s needs and workflow. The software is not imported into a clinical environment–much less imposed on one–but grows organically from it, as early developers of the VistA software at the Veterans Administration claimed to have done. Problems with document exchange would be caught immediately during such a process, and the programmers would work out a common format cooperatively–because that’s what the clinicians want them to do.

August 13, 2014 I Written By

Karen DeSalvo’s Sit Down Interview with Shahid Shah at the Health Privacy Summit

At the 2014 Patient Privacy Summit, Shahid Shah had a “Fireside Chat” with Karen DeSalvo. The interview was really great because it was the first time that I’ve seen Karen DeSalvo talk in a more casual and less scripted setting. In the interview you learn a lot about the leader of ONC and what’s on her mind and how her and ONC plan to approach healthcare IT in the future. Of course, since it’s at the Patient Privacy Summit, there’s a specific emphasis on privacy, but they also cover a lot of other related topics. Enjoy!

August 7, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 15 blogs containing almost 6000 articles with John having written over 3000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 14 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John launched two new companies: InfluentialNetworks.com and Physia.com, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus. Healthcare Scene can be found on Google+ as well.

ONC’s Authority to Regulate Health IT

New National Coordinator for Health IT, Karen DeSalvo, is facing a really interesting time for ONC. The meaningful use money is close to running out and so DeSalvo has to figure out how to assure the future of the ONC organization. A part of me wonders if Farzad saw this stage of the organization coming and got out while the getting was good. Regardless, ONC has always had a challenge getting funding for its health IT efforts and with meaningful use funding close to the end it’s going to be an even bigger challenge.

I think as part of this future one option would be for ONC to become the safety and risk based regulatory body for health IT. Although, this idea has been questioned by the House Energy and Commerce Committee in a letter embedded below.

I don’t want to dive deep into the politics and regulations around this since it’s not my area of expertise. Instead, I want to discuss at a high level ONC’s future and the balance between ONC and the FDA. I’ve written about the FDA regulation of EHR before. I don’t see it happening. I don’t think it will happen and I don’t think they have the skills to make it happen.

On the other hand, should ONC start regulating it? I don’t think they have the skills or expertise either to do it effectively. Not only do they not have the funding (and that’s unlikely to change), but I don’t think they have the people who can accomplish this task. Plus, I don’t think they should regulate EHR.

I do wish that ONC would go all in on dealing with interoperability of health data. If they did this, then ONC would be an important part of healthcare’s future.

What do you think of ONC and its future? What should they be working on? What could they do to really have an impact for good on the future of health IT in the US?

July 3, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 15 blogs containing almost 6000 articles with John having written over 3000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 14 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John launched two new companies: InfluentialNetworks.com and Physia.com, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus. Healthcare Scene can be found on Google+ as well.

Direct Messaging: The Logistics of Exchange

Once you enable digital health data exchange via Direct instead of by fax, you’ll want to share your address with other providers, so you no longer have to deal with all those pesky scanned attachments, subtly linked to electronic patient records.

Direct directories are enabling address lookup to meet this need, and you can also let your most common business partners know your address by including it on document templates you already exchange today, so they can begin to exchange with you via Direct when they’re ready.  You can also contact your referring docs using another method you trust (such as the fax where you usually send them medical records, or their business phone number) to ask for their Direct address.

It’s wise to confirm expectations with exchange partners about the use cases/data payloads for which you intend to exchange via Direct, as Direct isn’t used just like email by everyone.  Some will use Direct solely for Transitions of Care and patient Transmit, others may use it for Secure Messaging with patients, and still other providers will be happy to conduct general professional correspondence with patients and other providers over Direct.  This service information may or may not be reflected in the first provider directories.  And even within the Transitions of Care use case, if standards aren’t implemented for optimal receiving, a sending system may generate a CCDA (Continuity of Care Document) with a subtly different structure than a receiving system is able to completely digest.  So, just a heads up as you receive your first message or two from a system with whom you haven’t exchanged before: you’ll want to carefully monitor what data is incorporated by the receiving system and what is not, and you may need to iterate slightly between sender and receiver to get the data consumption right.  You’ll still be miles ahead of the custom interfaces model.

All in all, Direct is easy to use and is working much better than the naysayers would have you believe.  Direct software follows the specification outlined in the document lovingly known in the industry as the “Applicability Statement”, crafted by consensus through a public/private collaborative effort known as the “Direct Project” and led by the Office of the National Coordinator of Health Information Technology (ONC).   Direct Project volunteers have also written reference implementations following this specification which have been used by many HISPs and EHRs as the basis for their own Direct offerings.  Other private entities have developed their own APIs and implementations of the protocol from scratch.  These different systems and varying configurations regularly test and collaborate with each other, to make Direct work as seamlessly as possible for the end users.  Because the whole system only works as well as our joint efforts, HISPs (Health Information Service Providers who provide Direct services) within the DirectTrust Network take interoperability seriously and work together to iron out any kinks.

A tremendous amount of collaboration is taking place to bring interoperability to fruition for Direct’s well-established standards and policies, and this work is producing a larger and more robust network each day.

June 12, 2014 I Written By

Julie Maas is Founder and CEO of EMR Direct, a HISP (Health Information Service Provider) whose mission is to simplify interoperability in healthcare through the use of Direct messaging EHR integration and other applications. EMR Direct works with a large developer community to enable Direct for MU2 and other workflows using a custom, rapid-integration API that's part of the phiMail Direct Messaging platform. Julie is passionate about improving quality of care and software user experience, and manages ongoing interoperability testing within DirectTrust. Find Julie on Twitter @JulieWMaas.

Has EHR Become a Bad Brand?

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 noting like a tragedy to grab public attention and move decision makers off the dime. I don’t want it to occur this way, but nothing like a tragedy 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.

April 25, 2014 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

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

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.

March 31, 2014 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

NIST Dissects Workflow: Is Anyone Biting?

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?

March 26, 2014 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

Physician Designed EHR, EHR MU Documentation, and Top EHR Ratings Lists


I really hate this discussion. It reminds me of the republican-democrat debates. They always go too far and both sides (in this case Physicians and EHR vendors) often only see their side and miss the opposite viewpoint. It’s very polarizing. The best situation is the mix of both sides of the equation. Plus, you usually need someone who can help translate and moderate between the two viewpoints. That’s much easier said than done. You can definitely learn a lot about an EHR vendor when you learn if they’re more physician designed or tech designed.


Many people unfamiliar with these standards probably don’t undstand this tweet from Mandi since they assume it’s a standard and so the ONC documentation should be good enough, no? The reality is that every implementation of the ONC standard is different and you have to have documentation of how that EHR vendor implemented the standard.


I appreciate Chandresh’s tweet more than most. I’ve often considered the idea of starting an EHR rating site. They are a dime a dozen and I don’t think any of them are very good. The best ones use some high level filters to help you narrow the search. This has some value, but isn’t really an EHR rating site. The problem with an EHR rating is the sheer scale of responses that you need to collect for it to be valuable. There are 300+ EHR vendors. There are 40+ specialties. There are practices from solo doctor up to hundreds in a multi specialty clinic. There are 50 states. There are hundreds of insurance plans. You get the picture. The number of randomly collected quality ratings you would need is impossible. I enjoy a good list as much as the next person, but just remember what I mention above when you see the next list of Top EHR vendors.

Then again. Maybe Chandresh and I should get together and do an EHR rating service based on if the EHR was a physician designed or tech designed EHR.

March 16, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 15 blogs containing almost 6000 articles with John having written over 3000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 14 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John launched two new companies: InfluentialNetworks.com and Physia.com, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus. Healthcare Scene can be found on Google+ as well.

An Eclectic Gathering of EHR Usability and Project Resources

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.

March 10, 2014 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

ONC Releases Findings on Study of Patient-Matching Practices

The ONC has released findings from its study of patient-matching practices in the private sector and federal agencies.

Its conclusion: standardizing specific demographic fields within health IT systems and broad collaboration on industry best practices are two of the key steps the industry needs to take to make advances in patient matching.

In its study, ONC was looking to describe common data attributes, processes, and best practices to assess the industry’s current capabilities in this area. To do so, it did an environmental scan to get a look at current industry capabilities, literature review, feedback received at public meetings, collaboration with federal partner agencies and written comments stakeholders.

Problems it found include differences in the way names and addresses are formatted in various systems which can lead to high rates of unmatched records.

According to a story in FierceHealthIT, the study’s key recommendations include the following:

* Certification criteria should be introduced that require certified electronic health record technology to capture the data attributes that would be required in the standardized patient identifying attributes
* The ability of additional, non-traditional data attributes to improve patient matching should be studied
*Certification criteria should not be created for patient matching algorithms or require organizations to utilize a specific type of algorithm
*Work with the industry to develop best practices and policies to encourage consumers to keep their information current and accurate is necessary

With these me just at the suggestion stage, it’s evident that patient matching needs more attention.

In the past, the ONC has suggested hospitals create a standardized patient identifier during data transactions to make sure the right patient is matched with the correct information. But that won’t address the problem higher-order problem.

Simply being aware that data mismatches on patients a problem is a good first step, but it looks like we have a long way to go before data can be shared from institution to institution accurately without duplicate records and other errors of this type. Interoperability between institutions which allows for accurate patient matching is the real brass ring.

February 28, 2014 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @annezieger on Twitter.