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!

Open Standards Advance in Health Care Through the Appeal of FHIR and SMART

Posted on October 13, 2014 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site ( and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The poor state of interoperability between EHRs–target of fulminations and curses from health care activists over the years–is starting to grind its way forward. Dr. Kenneth Mandl, a leader of the SMART Platform and professor at the Boston Children’s Hospital Informatics Program, found that out when his team, including lead architect Josh Mandel, went to HIMSS this year to support Cerner’s implementation of his standard, and discovered three other vendors running it.

That’s the beauty of open source and standards. Put them out there and anyone can use them without a by-your-leave. Standards can diffuse in ways the original developers never anticipated.

A bit of background. The SMART platform, which I covered a few years ago, was developed by Mandl’s team at Harvard Medical School and Children’s Hospital to solve the festering problem of inaccessibility in EHRs and other health care software. SMART fulfilled the long-time vision of open source advocates to provide a common platform for every vendor that chose to support it, and that would allow third-party developers to create useful applications.

Without a standard, third-party developers were in limbo. They had to write special code to support each EHR they want to run on. Worse still, they may have to ask the EHR vendor for permission to connect. This has been stunting the market for apps expanding the use of patient data by clinicians as well as the patients themselves.

SMART’s prospects have been energized by the creation of a modern interoperability resource called FHIR. It breaks with the traditional health care standards by being lean, extendible in controllable ways, and in tune with modern development standards such as REST and JSON.

It helps that SMART was supported by funds from the ONC, and that FHIR was adopted by the leading health care standards group, HL7. HL7’s backing of FHIR in particular lent these standards authority among the vendor and health care provider community. Now the chocolate and peanut butter favored by health IT advocates have come together in the SMART on FHIR project, which I wrote about earlier this year.

Mandl explains that SMART allows innovators to get access to the point of care. As more organizations and products adopt the SMART on FHIR, API, a SMART app written once will run anywhere.

Vendors have been coming to FHIR meetings and expressing approval in the abstract for these standards. But it was still a pleasant surprise for Mandl to hear of SMART implementations demo’d at HIMSS by Intermountain, Hewlett-Packard, and Harris as well as Cerner.

The SMART project has just released guidlines for health care providers who want to issue RFPs soliciting vendors for SMART implementations. This will help ensure that providers get what they ask and pay for: an API that reliably runs any app written for SMART.

It’s wise to be cautious and very specific when soliciting products based on standards. The notion of “openness” is often misunderstood and taken to places it wasn’t meant to go. In health care, one major vendor can trumpet its “openness” while picking and choosing which vendors to allow use of its API, and charging money for every document transferred.

The slipperiness of the “open” concept is not limited to health IT. For years, Microsoft promulgated an “open source” initiative while keeping to the old proprietary practices of exerting patent rights and restricting who had access to code. Currently they have made great progress and are a major contributor to Linux and other projects, including tools used with their HealthVault PHR.

Google, too, although a major supporter of open source projects, plays games with its Android platform. The code is nominally under an open license–and is being exploited by numerous embedded systems developers that way–but is developed in anything but an open manner at Google, and is hedged by so many requirements that it’s hard to release a product with the Android moniker unless one partners closely with Google.

After talking to Mandl, I had a phone interview with Stan Huff, Chief Informatics Officer for Intermountain. Huff is an expert in interoperability and active in HL7. About a year ago he led an effort at Intermountain to improve interoperability. The motivation was not some ethereal vision of openness but the realization that Intermountain couldn’t do everything it needed to be competitive on its own–it would have to seek out the contributions of outsiders.

When Intermountain partnered with Cerner, senior management had by that time received a good education in the value of a standard API. Cerner was also committed to it, luckily, and the two companies collaborated on FHIR and SMART. Cerner’s task was to wrap their services in a FHIR-compliant API and to make sure to use standard technology, such as in codes for lab data.

Intermountain also participated in launching a not-for-profit corporation, the Healthcare Services Platform Consortium, that promotes SMART-on-FHIR and other standards. A lot of vendors have joined up, and Huff encourages other vendors to give up their fears that standardization is a catheter siphoning away business and to try the consortium out.

Intermountain currently is offering several applications that run in web browsers (and therefore should be widely usable on different platforms). Although currently in the prototype stage, the applications should be available later this year. Besides an application developed by Intermountain to monitor hemolytic disease among neonates and suggest paths for doctors to take, they support several demonstration apps produced by the SMART project, including a growth chart app, a blood pressure management app, and a cardiovascular app.

Huff reports that apps are easy to build on SMART. In at least one case, it took just two weeks for the coding.

Attendees at HIMSS were very excited about Intermountain’s support for SMART. The health care providers want more flexible and innovative software with good user interfaces, and see SMART providing that. Many vendors look to replicate what Intermountain has done (although some hold back). Understanding that progress is possible can empower doctors and advocates to call for more.

What Happens When You Forget Your Laptop?

Posted on September 22, 2014 I Written By

John Lynn is the Founder of the 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 13 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Many people have long talked about the day when desktops and laptops will no longer exist. When you think about it, there is really nothing that couldn’t be done on your cell phone that can be done on a desktop or laptop.

Sure there are some applications that haven’t yet been made available on a cell phone (I mean natively. Of course a remote desktop environment can run anything) yet. However, every application could be made available on a cell phone if desired. The cell phone is powerful enough. Especially when attached to a powerful server. Yes, I know that many of the mobile apps aren’t as great as their desktop counterparts, but they could and will be.

If we could just use our cell phone for these applications, why don’t we? It admins would happily get rid of desktops and laptops in order to have a much smaller device footprint that they have to manage. It would take some time to make the switch, but it would happen.

The biggest reason I think we have yet to go all in with cell phones as our primary device is the value of peripherals. I think we seriously underestimate the value of a decent keyboard and extra screen real estate.

I’m amazed at how well you can type on a cell phone keyboard, but it still pales in comparison to a quality keyboard. Voice recognition might help in some situations, but it can’t be used everywhere a keyboard can be used. I don’t see us ever beating a physical keyboard at least until it starts typing our thoughts.

Screen real estate is an even bigger issue. As much as you shrink the internals of a cell phone you’re still bound by the size of the screen. Just look at Apple’s choice to release an iPhone with a larger screen. We love as much screen space as we can get. If you’ve never had the delight of using dual monitors on your desktop, you have no idea the efficiencies you’re missing out on. I can do everything on my laptop that I can do on my desktop, but dual monitors makes doing so much more effecient. I even bought a second monitor I could plug into the USB on my laptop. It’s that valuable.

I think the clear solution to this problem is to be able to easily connect your cell phone to external “monitors” and other peripherals like keyboards. Soon these connections will all be available wirelessly. I put “monitors” in quotes since I think we’ll have electronic viewing areas on everything from windows to tables and everything in between. That’s an exciting future to consider (we’ll leave the security issues for another post).

Unfortunately, we’re not there yet, but I think it’s where we’re headed. Eventually we’ll sit down at our desk where our cell phone will wirelessly connect to the monitors and peripherals on your desk. Until then we do this awkward dance between cell phone, laptop and desktop.

In fact, I just boarded a flight with my laptop charging at home instead of being in my laptop bag. Now I get to see first hand the difference between my laptop and cell phone on a work trip. If only the seat back was a monitor and the tray table a keyboard I could connect to my cell phone. Then, I’d been in business and wouldn’t even need my laptop. One day!

Afterthought: This is definitely a first world problems” post. Also, excuse any typoes, because I wrote this post in air on my cell phone keyboard. Certainly the lack of keyboard and monitor didn’t stop me from doing this post, but I could have probably done it twice as fast. Although, it’s a bit ironic that this post wouldn’t exist if the tech was already available. If you’ll be at the Insite Build conference in Fargo, ND, we’ll see you there. Just don’t be surprised if I ask to borrow your laptop.

Another EHR Glass Implementation

Posted on July 18, 2014 I Written By

John Lynn is the Founder of the 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 13 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

HealthTech has a really terrible write up of the latest EHR vendor to put out a Google Glass EHR implementation. The iPatientCare EHR application is called miGlass. However, the article states that it’s the first wearable EHR App for glass, but we’ve already written about one from DrChrono and Kareo’s Google Glass implementation was probably the first one that I saw. Plus, there are a number of hospital based EHR implementations that have happened as well. Maybe iPatientCare was the first and they just didn’t get any coverage until now.

Timing aside, the article lists the technology available on this new Google Glass EHR application, miGlass:

  • Web browser based EHR and PM System
  • Microsoft .net Technology
  • Services Oriented Architecture
  • HL7 CCD and ASTM CCR for Interoperability
  • HL7 Integration with leading Lab
  • Information Systems
  • SureScripts/RxHUB Certified ePrescribing
  • Reporting & Analytics using Cognos and Business Objects
  • Available on iPhone and iPad

Maybe the article just made a mistake (I make them all the time as you know), but that list seems like a list of EHR technology and not Google Glass application functionality. iPatientCare also has a video that’s not even worth linking to since it doesn’t say anything about what the Google Glass application really does.

While I love to see EHR vendors experimenting and testing the integration of Google Glass into their EHR, I still haven’t seen the killer use case in action. Although, there are a few hospital EHR Google Glass implementations that I’d like to see in action. I do love the potential of Google Glass. There’s something beautiful about an always on, always connected application that’s sitting there waiting for you when it’s needed. Plus, as the camera recognition technology gets better, the workflow will get better as well.

Imagine walking into an exam room and as you do it, your Google Glass scans a QR code on the door and pulls up the patient waiting for you in the room. Hopefully that’s the naive and simplistic view of where the technology is going to be taken. As more EHR vendors tinker with the technology it will be really interesting to see what becomes a reality.

Hospital CIOs Cutting Back on Non-Essential Projects

Posted on July 10, 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 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.

Generally speaking, cutting back on IT projects and spending is a tricky thing. In some cases spending can be postponed, but other times, slicing a budget can have serious consequences.

One area  where cutting budgets can cause major problems is in preparing to roll out EMRs, especially cuts to training, which can lead to problems with rollouts, resentment, medical mistakes, system downtime due to mistakes and more.  Also, skimping on training can lead to a domino effect which results in the exit of CEOs and other senior leaders, which has happened several times (that we know of) over the past couple of years.

That being said, sometimes budgetary constraints force CIOs to make cuts anyway, reports FierceHealthIT Increasingly projects other than EMRs are falling in priority.

A recent survey of hospital technology leaders representing 650 hospitals nationwide published by HIMSS underscores this trend. Respondents told HIMSS said that despite increases in IT budgets, they still struggled to complete IT projects due to financial limitations. In fact, 25 percent said that financial survival was their top priority.

What that comes down to, it seems, is that promising initiatives fall by the roadside if they don’t contribute to EMR success.  For example, providers are stepping back from HIE participation because they feel they can’t afford to be involved, according to a HIMSS Analytics survey published last fall.

Instead, hospitals are taking steps to enhance and build on their EMR investment. For example, as FierceHealthIT notes, Partners HealthCare recently chose to pull together all of its EMR efforts under a single vendor.  In the past, Partners had used a combo of homegrown systems and vendor products, but IT leaders there  felt that this arrangement was too expensive to continue, according to Becker’s Hospital Review.

This laser focus on EMRs may be necessary at present, as the EMR is arguably the most mission-critical software hospitals have in place at the  moment. The question, as I see it, is whether this will cripple hospitals in the future. Eventually, I’d argue, mobile health will become a priority for hospitals and medical practices, as will some form of  HIE participation, just to name the first two technologies that come to mind. In three to five years, if they don’t fund initiatives in these areas, hospitals may look  up and find that they’re hopelessly behind .

Allscripts And Team Battle Epic and IBM for DoD Contract

Posted on June 27, 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 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.

Earlier this month,we shared the news that Epic and IBM had gotten together to fight for the DoD’s massive Healthcare Management Systems  Modernization project. The project is to replace the current Military Health System, which should serve some 9.7 million beneficiaries.  The winning team should make about $11 billion to do the work.

So it’s little wonder that another group of health IT giants have stepped up to fight for such a juicy prize.  A group lead by Computer Sciences Corp., whose partners include Allscripts and HP, has announced that it intends to compete for the contract.

The HMSM project is extremely ambitious. It’s intended to connect varied healthcare systems across the globe, located at Army hospitals, on Naval vessels, in battlefield clinics and more, into a single open, interoperable platform serving not only active-duty members, but also reservists and civilian contractors.

Before you burst out laughing at the idea that any EMR vendor could pull this off, it’s worth considering that perhaps their partners can.  It’s hard to argue that CSC has a long track record in both government and private sector health IT work, and HP has 50 years with of experience in developing IT projects military health and VA projects.

That being said, one has to wonder whether Allscripts — which is boasting of bringing an open architecture to the project — can really put his money where its mouth is. (One could say the same of Epic, which frequently describes its platform as interoperable but has a reputation of being interoperable only from one Epic installation to the other.)

To be fair, both project groups have about as much integration firepower as anyone on earth. Maybe, if the winner manages to create an interoperable platform for the military, they’ll bring that to private industry and will see some real information sharing there.

That being said, I remain skeptical that the DoD is going to get what it’s paying for; as far as I know, there is no massively interoperable platform in existence that meets the specs this project has.  That’s not an absolute dealbreaker, but it should raise some eyebrows.

Bottom line, the DoD seems determined to give it a try, regardless of the shaky state of interoperability in the industry overall. And its goals seem to be the right ones. After all, who  wouldn’t want an open platform that lends itself to future change and development?  Sadly, however, I think it’s more likely that will be shaking our heads over the collapse of the project some years from now.

Will Outsourcing VA Care Monkey Wrench VistA?

Posted on June 16, 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, 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.

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.

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

Posted on 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, 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.

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.

NIST Dissects Workflow: Is Anyone Biting?

Posted on 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, 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.

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?

#HIMSS14 Highlights: the Snail’s Pace of Interoperability

Posted on February 26, 2014 I Written By

As Social Marketing Director at Billian, Jennifer Dennard is responsible for the continuing development and implementation of the company's social media strategies for Billian's HealthDATA and Porter Research. She is a regular contributor to a number of healthcare blogs and currently manages social marketing channels for the Health IT Leadership Summit and Technology Association of Georgia’s Health Society. You can find her on Twitter @JennDennard.

Ah, HIMSS. The frenetic pace. The ridiculously long exhibit hall. The aching feet. The Google Glass-ers. As I write this, day three for me is in full swing and I’ve finally managed to find some time to reflect on what I’ve seen, which includes a ridiculously long taxi queue at the airport, more pedicabs than I can count, beautiful weather and lots of familiar faces, which is what makes HIMSS so much fun. I’ve heard lots of buzzwords and sales talk, and seen only about an eighth of the exhibit hall, barely scratching the surface of what’s out there on the show floor.

Several common themes stand out based on the sessions and events I’ve been to, and the passions of those I’ve encountered. Whether it’s vendor breakfasts, social networking functions, exhibit elevator pitches or educational sessions, interoperability and engagement are still the buzzwords to beat. This particular HIMSS has given me a different perspective on each, and offered new insight into what’s happening with the Blue Button Connector. I’ll cover each of these in HIMSS Highlights posts over the next several weeks, starting with interoperability.

The industry seems far more realistic this year regarding interoperability – downright frustrated by the slow pace at which such a lofty goal is proceeding. Industry experts Brian Ahier and Shahid Shah perhaps expressed it best during a lively panel discussion at the Surescripts booth:





Putting vendors’ feet to the fire will certainly initiate a quick and painful reaction, but probably not a sustainable one. True momentum will occur only when providers get singed a bit, too. Panelist comments at a Dell / Intel breakfast on analytics for accountable care brought this into sharper focus for me. The fact that too many disparate EMRs (and thus too many vendors poised to cause inertia) are making it hard for analytics to successfully be adopted and utilized at an enterprise level, highlights a bigger problem related to hindsight and strategy.

From my perspective – that of an industry observer and commentator – it seems many providers felt compelled to purchase EMRs because the federal government offered them money to do so, and hopefully just as many were optimistic about the role technology would play in positively affecting patient outcomes. Vendors saw a great business opportunity and moved quickly to develop systems that met Meaningful Use criteria (not necessarily going for best-fit as related to workflow needs and usability). Neither group truly knew what they were in store for, especially regarding longer term plans for health information exchange.

Providers now find themselves wanting to move forward with health information exchange and greater interoperability, but slowed down by the very IT systems they were so insistent on purchasing just a few years ago. Vendors (some more than others) are hesitant to crack open their products to allow data to truly flow from one system to another, and who can blame them? The EMR market, in particular, is poised to shrink, which begs the question, who will survive? What companies will be around at HIMSS 15 and 16? Those who keep their systems siloed, like Epic? Or those who are trying to break down the silos, such as Common Well Alliance members like athenahealth and Greenway?

It makes me wonder if providers wouldn’t have been better served with just had a handful of EMRs to choose from around the time of HITECH, all guaranteed to evolve as needed and play nicely with each other in the interest of health information exchange. Too many options have caused too many barriers. That’s not just my opinion, by the way. I’m willing to bet that a sizeable chunk of the 37,537 HIMSS 14 attendees would agree with me.

Do you disagree? Are providers (and patients) better served by more IT options than less? Let me know your thoughts, and impressions of interoperability advancement at HIMSS, in the comments below.

Practice Fusion’s Free Chromebook Comes at a High Price

Posted on February 4, 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, 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.

Update (4/2/14): I just got word that Practice Fusion has updated their terms page and removed the negativity clause.

Practice Fusion’s offering a free Google Chromebook to docs who sign up for its free, web EHR. It’s one thing to give’em the razor and charge for the blades, but this offering goes that one better, you get both, gratis. Or so it seems, but there is a catch you should know about before you click in.

The Deal

The heart of the offer is a free Google Chromebook worth about $300. Chromebooks are hardware platforms for Chrome’s browser, which acts as its operating system. They come in two screen sizes, eleven and fourteen inch and are made by several different vendors, such as HP and Toshiba. Google also provides 100 gigs of on line storage for two years.

Cromebooks have lightweight magnesium cases, a 1366 x 768 screen, 2 USBs, webcam, 2 gigs of RAM and a 16 gig solid state drive. They are WiFi only devices with Bluetooth. PF does not specify which vendor’s unit or screen size that it offers, though it refers to HP’s as an example. As a side note, John has the HP Chromebook and loves it and especially the 10-12 hours of battery life.

The Offer

To qualify, PF requires that you meet these standards:

  • License. Be a licensed US healthcare provider at least 18 years old. (Sorry, Doogie)
  • Status. Be a US Citizen or permanent legal resident
  • New User. Not been a PF user before
  • Account. Successfully signed up for a PF account
  • Rx User. Become one of their e-Prescribing users
  • Survey. Participate in a PF survey of eligible users
  • Agreement. Agree to their terms and conditions for the program.

As you would expect, PF puts in several clauses to protect itself and to comply with privacy and similar considerations. Oddly, I could not figure out what happens to the Chromebook if you quit PF or if they end the program.

The Gag Rule

So far, so good, but there’s a gotcha in Section 5d of the offer’s terms and conditions, which says:

Negativity. You will not disparage Practice Fusion, Inc., our Services, the Program, products, employees, partners, affiliates, contractors, or portray them in a negative or derogatory manner.

I don’t know what prompted PF to put this in. There’s nothing new in the PF technology or using a Chromebook to access it. It’s understandable that PF wants to make sure it’s getting new subscribers who are doctors, but this language is not related to the offer. It’s not part of PF’s standard agreement, which has nothing like this clause.

It’s easy to come up with questions about the language. Here are a few:

  • Scope. Just who isn’t included in this rule? It applies not only to PF and its employees, but also in this case to Google or HP, etc., including their contractors without limit.
  • Disparage. What do they mean by disparage, they don’t say. Commonly, it means to belittle or demean. So, if I say to a friend that my Chromebook’s OK, but it’s no MacPro, is that a violation? What if I post a problem on PF’s Community Support forum that’s an impediment to my work, am I liable under this section?
  • Negative or Derogatory Manner. I guess this means if you are going to say something less than flattering, you’ll have to damn with fait praise. For example, “Considering how short staffed they are, it’s amazing their backlog isn’t worse.”
  • Reviews. If I’m a doc who writes a review of PF under this program, am I barred from pointing out problems? Do they have a right to sue me for violation of the terms, if they think I said something negative?
  • Legal Recourse. If I file a complaint with a consumer protection agency, the FTC, FDA, etc., does this section open me to legal action?

All these are problematic, but the greatest problem with this clause, and similar ones that other vendors impose, is not what it does to their users. It’s what it does to the vendor and its products. These gag rules, which are intended to insulate the vendor from hostile comments, etc., also isolates them from important feedback.

As I’ve noted elsewhere about the gag rules some vendors include:

Agreements. Your company lawyer did a great job of protecting you from being sued. Are you so protected, though, that your client can’t talk about problems? Client complaints may be on target or way off, but if they are afraid to tell you or discuss it with anyone, how will you know?

With Section 5d’s language, PF thinks it’s shielding itself from adverse attacks, but it’s really blinding itself to legitimate criticism and suggestions for improvement.

There is also one other factor. PF has put this language in a program aimed at practicing physicians. Shouldn’t these doctors be considered partners in their efforts to make a quality EHR? Why would Practice Fusion not want both positive and negative feedback from these core users?

Maybe this was just missed by the Practice Fusion team and wasn’t their intent. It’s not hard in these situations for a legal team to add something that’s not the intent of the company and is missed in the terms review by the company. Balancing the legal is hard, but PF ought to trim this language way back or just toss it.