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!

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

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

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

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

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

MEDTECH Act’s Impact

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

EHRs and Adverse Events

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

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

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

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

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

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

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

ECRI on EHR Adverse Events

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

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

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

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

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

The MEDTECH Act’s Effects

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

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

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

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

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

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

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

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

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

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

Contradictory Terms

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

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

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

What’s It Mean?

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

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

Does Meaningful Use Inspire Innovative or Mediocre Systems?

Posted on December 12, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 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 InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I was absolutely intrigued by Dr. Webster’s tweet about the impact of meaningful use (MU) and the types of systems it inspires. I think everyone would agree that MU has done nothing to inspire innovative EHR systems to be created and I think most would agree that it’s mostly fostered the creation of mediocre systems.

I’m not saying that meaningful use has no redeeming qualities. It definitely drove adoption of EHR software. Some of the meaningful use requirements like ePrescribing and CPOE were already moving forward for many organizations and meaningful use threw gas on those fires. I think those will turn out to be really beneficial components to meaningful use.

We could talk about the overall impact of MU (good or bad), but I’m not sure how productive of a conversation that would be. Meaningful Use is the reality of today. So, instead of focusing backwards on something we can’t change, I’m interested to think about what meaningful use could become. For all intents and purposes, that’s going to be called meaningful use stage 3 (unless ONC decides to spend time on a rebranding).

The key question: Could Meaningful Use inspire innovative EHRs and other innovative health IT?

While I’m skeptical of government regulation doing much for innovation, I think there’s a chance that this could happen. The key change will be that meaningful use needs to move away from its prescriptive approach and requirements. Innovation rarely comes from prescriptive approaches to anything.

Instead of being so prescriptive, meaningful use should focus on creating frameworks for which innovation can happen. My initial analysis of FHIR is that this is directionally right when it comes to inspiring innovation in healthcare IT. I need to dig into the details a bit more, but the concepts of creating an open framework for health IT companies to innovate on top of EHR data is what things like meaningful use should incentivize. Reimbursement should help to encourage this type of innovation. HIPAA should be clarified to support this type of innovation.

RHIR is just one example and I’m sure there are many others. It’s an open approach which encourages the right things while not damaging those for which it doesn’t make any sense. To me that’s the major difference between a prescriptive requirements list versus a framework oriented approach.

Do we really care that doctors game the system to be able to meet the 5% patient engagement requirement of meaningful use? What value does that provide the healthcare system if they’re not truly engaging? That’s too prescriptive. I’m all for patient engagement. Doctors are too. However, these prescriptive MU requirements just cause doctors to game the system as opposed to truly engage.

What do you think could be done with MU so that it inspires innovative EHRs instead of mediocre systems?

Effective EHR Use and Customization with Ron King from Comtron

Posted on December 11, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 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 InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

In this interview we sit down with Comtron’s VP of Business Development, Ron King to cover a bit of background on Comtron and their Medgen EMR. We also talk about the key to effective EHR use and the need for EHR customization. Then, we also dive into meaningful use and ACOs and how a clinical practice should handle those regulations.

Communities Help Open Source Electronic Health Records Thrive (Part 2 of 3: OSEHRA)

Posted on December 9, 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 (http://radar.oreilly.com/) 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 first article of this series tried to convince you that community is important, and perhaps even the secret weapon behind open source software. Some open source project leaders understand this better than others, so a range of approaches to community has been developed.

In this article I’ll jump right in on the most critical open source project in health care–the famous VistA electronic health record–while saving some other impressive, although less well known, projects for the final article in the series.

Many open source projects in health IT don’t try to build communities. They feel that they put out useful software and they hope people use it–but they don’t do the work that, for instance, attendees at Community Leadership Summits have put in to make sure they make community members full-fledged partners in their work.

Brady Mathis, a health IT developer, discovered this problem when he became an enthusiastic adopter of the Tolven EHR. He told me that the project leaders seemed to lack a focus on community–a lapse all too easy to observe across many health IT projects. Specifically, he observed little responsiveness on forums, and when his firm offered back code improvements, he found no plan for developer contributions and guarded interest from the project team. However, he remains an enthusiastic support of Tolven, as one can see in a recent article he wrote, and he hopes to help it develop more involvement by its community.

The most famous open source EHR is VistA, and it has been widely adopted around the world (notably in Norway and Jordan) but has not enjoyed the penetration one would expect from such a mature product in the United States. As we saw in my previous article, the state of community around VistA may be implicated.

VistA has one of the most unusual histories of any open source project. As documented in Phillip Longman’s book, Best Care Anywhere, its primeval development was a famously grass-roots efforts by doctors and IT experts in the Veterans Administrations (now the Department of Veterans Affairs). VistA ultimately was accepted by VA management and recognized as a public resource that should be shared. Citing its code as public domain, the VA “threw it over the wall” (a phrase I have heard from VistA supporters) and continued to maintain it internally while having minimal contact with people outside.

A number of projects grew up around VistA, hoping to turn its illustrious success within the VA into an open source miracle in the rest of the globe. And indeed, the true community effort was the WorldVistA project. Several companies also grew up around VistA, two of whom I interviewed for a previous article about open source EHR projects.

All of these projects have survived, but none have broken through to the kind of success that VistA would seem to deserve in the swelling EHR market created by Meaningful Use. There could be many reasons for this inherent in VistA software. But I can’t find a technical reason. A basis in MUMPS, which makes VistA harder to understand, has not stopped companies such as Epic and InterSystems from reaching big adoption. Furthermore, the functions that the VA didn’t see as necessary (such as support for pediatricians) could be added by others.

Roger Maduro of Open Health News told me that licensing was a hurdle to pulling together a VistA community. As mentioned already, VistA itself is in the public domain. The WorldVistA team put their version under the GNU Public License (GPL), which has worked well for Linux and many other free software projects. But other GPL projects use programming languages that allow commercial projects to be built on top of a free software base, but the MUMPS language underlying VistA does not allow that.

The ungainly relationship between the VA and the putative community thus becomes an obvious candidate for improvement. And in 2011, the VA took decisive action in that area.

The VA had observed the success of many open source communities, notably the Apache web server, a project created totally by a committed community. Web servers are some of the most important software in the world (being the means by which people read this article and millions of other sites), and Apache has been the leader in this area for many years.

It so happens that one of the Apache leaders, Brian Behlendorf, also led one of the key open source projects promoted by the US government in health care, the CONNECT project for health information exchange. The VA consulted with Brian and others to develop an audacious plan for creating a healthy open source community out of the disparate stakeholders in VistA. The result in 2011 was the Open Source Electronic Health Record Alliance (OSEHRA).

OSEHRA has learned the lessons of successful community-building from other open source projects and has pursued them doggedly. They solicit input from users as far afield as Jordan and India, major users of VistA software. So far, these foreign collaborators have not returned changes. Culture change is hard, especially across cultures!

In an interview with Seong K. Mun, President and CEO of OSEHRA, I learned that it uses regular summits to develop “two-way conversations.” One success is contributions to a fundamental module called Fileman. The current version (20.2) was developed by a community over two-year period, with up to 20 people participating in discussions. The WorldVistA team reportedly feels sidelined by OSEHRA, but a fresh approach was needed.

In particular, OSHERA knew they had to get rid of the proprietary variants created over time by the companies that market VistA software. They needed one, consummately unified version of VistA across the VA and all outside users. As suggested by my earlier article, they are inspiring vendors to contribute code back to this harmonizing project.

However, when VistA felt it needed to do a major refactoring of VistA, it did not ask the community to step up, but hired a consulting firm. The sense I got from VistA supporters was that this job was too big for the current community community to take on. I suspect that, in particular, it required MUMPS skills the community didn’t have.

It’s hard to decide whether technical upgrades or community upgrades are harder. OSEHRA is dealing with both, and with notable success. My next article will deal with other open source projects dealing with community.

Fitbit Data Being Used In Personal Injury Case

Posted on December 8, 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 @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Lately, there’s been a lot of debate over whether data from wearable health bands is useful to clinicians or only benefits the consumer user. On the one hand, there are those that say that a patient’s medical care could be improved if doctors had data on their activity levels, heart rate, respirations and other standard metrics. Others, meanwhile, suggest that unless it can be integrated into an EMR and made usable, such data is just a distraction from other more important health indicators.

What hasn’t come up in these debates, but might far more frequently in the future,  is the idea that health band data can be used in personal injury cases to show the effects of an accident on a plaintiff. According to Forbes, a law firm in Calgary is working on what may be the first personal injury case to leverage smart band data, in this case activity data from a Fitbit.

The plaintiff, a young woman, was injured in an accident four years ago. While Fitbit hadn’t entered the market yet, her lawyers at McLeod Law believe they can establish the fact that she led an active lifestyle prior to her accident. They’ve now started processing data from her Fitbit to show that her activity levels have fallen under the baseline for someone of her age and profession.

It’s worth noting that rather than using Fitbit data directly, they’re processing it using analytics platform Vivametrica, which uses public research to compare people’s activity data with that of the general population. (Its core business is to analyze data from wearable sensor devices for the assessment of health and wellness.) The plaintiff will share her Fitbit data with Vivametrica for several months to present a rich picture of her activities.

Using even analyzed, processed data generated by a smart band is “unique,” according to her attorneys. “Till now we’ve always had to rely on clinical interpretation,” says Simon Muller of McLeod Law. “Now we’re looking at longer periods of time to the course of the day, and we have hard data.”

But even if the woman wins her case, there could be a downside to this trend. As Forbes notes, insurers will want wearable device data as much as plaintiffs will, and while they can’t force claimants to wear health bands, they can request a court order demanding the data from whoever holds the data. Dr. Rick Hu, co-founder and CEO of Vivametrica, tells Forbes that his company wouldn’t release such data, but doesn’t explain how he will be able to refuse to honor a court-ordered disclosure.

In fact, wearable devices could become a “black box” for the human body, according to Matthew Pearn, an associate lawyer with Canadian claims processing firm Foster & Company. In a piece for an insurance magazine, Pearn points out that it’s not clear, at least in his country, what privacy rights the wearers of health bands maintain over the data they generate once they file a personal injury suit.

Meanwhile, it’s still not clear how HIPAA protections apply to such data in the US. When FierceHealthIT recently spoke with Deven McGraw, a partner in the healthcare practice of Manatt, Phelps & Phillips, she pointed out that HIPAA only regulates data “in the hands of, with the control of, or within the purview of a medical provider, a health plan or other covered entity under the law.”  In other words, once the wearable data makes it into the doctor’s record, HIPAA protections are in force, but until then they are not.

All told, it’s pretty sobering to consider that millions of consumers are generating wearables data without knowing how vulnerable it is.

FHIR is on Fire

Posted on December 5, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 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 InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Ever since the announcement yesterday about Project Argonaut, FHIR has been getting some widespread coverage. Although, even before this important announcement, I was hearing a lot of people talk really optimistically about the potential of FHIR for healthcare. However, with Project Argonaut, you get all of these big name organizations on board as well:

  • athenahealth
  • Beth Israel Deaconess Medical Center
  • Cerner
  • Epic
  • Intermountain Healthcare
  • Mayo Clinic
  • MEDITECH
  • McKesson
  • Partners HealthCare System
  • SMART at the Boston Children’s Hospital Informatics Program
  • The Advisory Board Company

That’s quite a list of powerhouses that are investing money behind FHIR. I’m excited that the majority of major hospital EHR are represented in that list. Although, I do wonder if this is a lot of the same people who ruined CCDA. Let’s hope I’m wrong and they learned their lesson.

FHIR was also the topic of today’s #HITsm chat. Here are some of the tweets from the chat that caught my eye.


How’s that for optimism about the future of FHIR? Keith is deep in the trenches of health IT standards so he’s got a very informed opinion on what’s happening.


A very good sign since everyone I talk to seems to hate CCDA. They say that it’s bloated and really not usable.


I agree with Donald. The real question I have is whether FHIR will get us open APIs to the data we want. I need to investigate more to know the answer to that question.


I generally think this is true also, but not if it is a limited set of data. If you limit the data and don’t provide write back function, then there’s a real limit on what you can do with that data. Of course, you can start with some functionality and then build from there.


I’m still early on in my understanding of FHIR. I’m doing a whole series of posts on EMR and HIPAA around interoperability and the challenges associated with interoperability. You can be sure that FHIR will be a major part of my research and discussion. The above links look like a good place to start.

Please add your thoughts on FHIR in the comments as well.

Adverse Event Reporting: What Is It?

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

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

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

The FDA: Ground Zero for Adverse Event Reports

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

  • Medicines
  • Medical Devices, and
  • Vaccines.

Four FDA systems cover these classes:

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

MEDSUN Reporting Poster

State Adverse Event Reporting Systems

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

Patient Safety Organizations

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

The Safety Reporting Paradox

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

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

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

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

Communities Help Open Source Electronic Health Records Thrive (Part 1 of 3: Justification)

Posted on December 2, 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 (http://radar.oreilly.com/) 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 value of community participation is a major topic among open source software projects. When people draw together around a project, talk about it (and argue passionately about it) among themselves, offer advice, contribute code, fix bugs, and generally consider themselves one of the family–a robust, highly engaged community seems to be a magical force that determines whether an open source project succeeds.

The correlation is strong. Great community participation: the project lasts forever. Poor community participation: the project stagnates and is widely seen as irrelevant.

The company I work for, O’Reilly Media, in recognition of the bond between community and open source, has sponsored a Community Leadership Summit for the past seven years in conjunction with our Open Source convention. Many other Community Leadership Summits are now held around the world. The founder of the summit also wrote a book called The Art of Community for O’Reilly. The health of an open source community is also assessed as one of the factors that let potential software users judge the project’s maturity, and therefore whether they feel trusting enough to put its software at the center of their own endeavors.

The next two articles in this series will examine various open source projects in the health IT space that have developed vibrant communities. But before we can appreciate the importance of those efforts, we need to understand why community is central to growth. That is the subject of this article.

Naturally, we have no randomized clinical trials to draw on, so we don’t really know why community and success are correlated in open source. It could simply be that good software draws interested people around it. But there are persuasive explanations for the apparent positive effect that communities have on projects.

Community members help each other get started with projects, solve problems among more knowledgeable users, advocate for the projects, make substantial contributions to code, and find ways to reward project developers and make them feel appreciated. Of course, some of these activities are done for proprietary projects as well, and for other companies of all types–just witness the loyalty of Apple users, Harley Davidson motorcycle drivers, In-N-Out Burger gourmands, and so forth.

Witnessing the value of community, many companies nowadays try to develop communities around their products or services. Many do it through social media campaigns (seeing how many “likes” they can get on Facebook, for instance), but these small boasts pale before the tangible contributions of an open source community. I believe community offers open source an unshakeable advantage over proprietary software in three ways.

  • Setting direction: by extending the software in ways they care about, and even creating the new building blocks at the core of a software project, community members ensure that a project stays relevant to its users. If the leaders of a project don’t recognize an important trend in the field, someone else will create the code to make sure the project supports that trend, and users will champion the adaptation. Whereas proprietary projects have to choose one or two directions that promise the most revenue, open source projects can permanently support niche uses. Nowadays, there is no stigma involved in changing the software and creating a whole new project based on an older one.

  • Continuity and trust: purchasers of proprietary software–and nowadays, users of online services–are at the mercy of the vendor. The developers of the software you depend on every day may go out of business, raise prices precipitously, or drop features you consider critical. I’ve heard numerous such horror stories and experienced a couple myself. Therefore, many users insist on open source software because it will stay around even if the original developers lose interest or try to move it in a different direction. A well-educated and motivated community can pick up an abandoned project and generate new developers.

  • Education: open source provides examples and models for people learning how to program, and these programmers in turn can serve the users of open source. Nothing gives you more insight into a project’s robustness and performance than looking inside the software. Paging through code gives a user a bond with the software comparable to that of a musician who makes his own instruments or a motorcyclist who services his own vehicle. Not everyone who uses software has the time and expertise to study the source code, but the few people who do can be resources for the rest of the community. They can usually describe the quirks and problems of the software better than the developers, who are too close to their own work to have the same empathy for users. Organizations can also hire a competent programmer to customize the code and meet their unique needs.

Community has been credited with one of the most notable successes in computing history: the rise of the Linux operating system. Many people–most notably, BSD proponents–have wondered why the august BSD operating system didn’t achieve the fame and dominance of Linux. Community is a formidable component of the answer.

BSD (which stands for Berkeley Software Distribution, a nod toward the university where it originated), a variant of the Unix operating system, was mature and widely used more than a decade before Linux was famously invented by 19-year-old college student Linus Torvalds. BSD was generally credited with having better programming interfaces than the original Unix developed by AT&T, and many of its library calls made it back into the “real” Unix. BSD was also adopted by many proprietary companies, and became in particular the basis of the great company Sun Microsystems, the most popular source for modestly priced computer systems for decades.

But BSD was not as innovative organizationally as it was technically. It was developed by a closed team that experienced disagreements and splits. Three different, incompatible versions of BSD still exist today (not even counting the version that underlies Apple products, and some other smaller branches).

In contrast, Linus Torvalds announced his project by posting it to the Internet and inviting others to contribute. He has proved an extremely adept project leader during the ensuing 23 years, a “benevolent dictator” in open source parlance.

Certainly, the computer field has evolved a great deal between the founding of the BSD project and the founding of the Linux project, and many factors can be credited in Linux’s success. But the organizational woes of the various BSD factions contrast strikingly with the fiercely fought but successfully contained debates within the Linux community.

Having surveyed the history of open source and the role of community, I’ll turn in the next article to successes within health IT.

By Supporting Digital Health, EMRs To Create Collective Savings of $78B Over Next Five Years

Posted on December 1, 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 @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Here’s the news EMR proponents have been insisting would emerge someday, justifying their long-suffering faith in the value of such systems.  A new study from Juniper Research has concluded that EMRs will save $78 billion cumulatively across the globe over the next five years, largely by connecting digital health technologies together.

While I’m tempted to get cynical about this — my poor heart has been broken by so many unsupportable or conflicting claims regarding EMR savings over the years — I think the study definitely bears examination. If digital health technologies like smart watches, fitness trackers, sensor-laden clothing, smart mobile health apps, remote monitoring and telemedicine share a common backbone that serves clinicians, the study’s conclusions look reasonable on first glance.

According to Juniper, the growth of ACOs is pushing providers to think on a population health level and that, in turn, is propelling them to adopt digital health tech.  And it’s not just top healthcare leaders that are getting excited about digital health. Juniper found that over the last 18 months, healthcare workers have become significantly more engaged in digital healthcare.

But how will providers come to grips with the floods of data generated by these emerging technologies? Why, EMRs will do the job. “Advanced EHRs will provide the ‘glue’ to bring together the devices, stakeholders and medical records in the future connected healthcare environment,” according to Juniper report author Anthony Cox.

But it’s important to note that at present, EMRs aren’t likely to have the capacity sort out the growing flood of connected health data on their own. Instead, it appears that healthcare providers will have to rely on data intermediary platforms like Apple’s HealthKit, Samsung’s SAMI (Samsung Architecture for Multimodal Interactions) and Microsoft Health. In reality, it’s platforms like these, not EMRs, that are truly serving as the glue for far-flung digital health data.

I guess what I’m trying to say is that on reflection, my cynical take on the study is somewhat justified. While they’ll play a very important role, I believe that it’s disingenuous to suggest that EMRs themselves will create huge healthcare savings.

Sure, EMRs are ultimately where the buck stops, and unless digital health data can be consumed by doctors at an EMR console, they’re unlikely to use it. But even though using EMRs as the backbone for digital health collection and population health management sounds peachy, the truth is that EMR vendors are nowhere near ready to offer robust support for these efforts.

Yes, I believe that the combination of EMRs and digital health data will prove to be very powerful over time. And I also believe that platforms like HealthKit will help us get there. I even believe that the huge savings projected by Juniper is possible. I just think getting there will be a lot more awkward than the study makes it sound.

Epic Tries To Open New Market By Offering Cloud Hosting

Posted on November 26, 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 @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

When you think of Epic, you hardly imagine a company which is running out of customers to exploit. But according to Frost & Sullivan’s connected health analyst, Shruthi Parakkal, Epic has reached the point where its target market is almost completely saturated.

Sure, Epic may have only (!) 15% to 20% market share in both hospital and ambulatory enterprise EMR sector, it can’t go much further operating as-is.  After all, there’s only so many large hospital systems and academic medical centers out there that can afford its extremely pricey product.

That’s almost certainly why Epic has just announced  that it was launching a cloud-based offering, after refusing to go there for quite some time.  If it makes a cloud offering available, note analysts like Parakkal, Epic suddenly becomes an option for smaller hospitals with less than 200 beds. Also, offering cloud services may also net Epic a few large hospitals that want to create a hybrid cloud model with some of its application infrastructure on site and some in the cloud.

But unlike in its core market, where Epic has enjoyed incredible success, it’s not a lock that the EMR giant will lead the pack just for showing up. For one thing, it’s late to the party, with cloud competitors including Cerner, Allscripts, MEDITECH, CPSI, and many more already well established in the smaller hospital space. Moreover, these are well-funded competitors, not tiny startups it can brush away with a flyswatter.

Another issue is price. While Epic’s cloud offering may be far less expensive than its on-site option, my guess is that it will be more expensive than other comparable offerings. (Of course, one could get into an argument over what “comparable” really means, but that’s another story.)

And then there’s the problem of trust. I’d hate to have to depend completely on a powerful company that generally gets what it wants to have access to such a mission-critical application. Trust is always an issue when relying on a SaaS-based vendor, of course, but it’s a particularly significant issue here.

Why? Realistically, the smaller hospitals that are likely to consider an Epic cloud product are just dots on the map to a company Epic’s size. Such hospitals don’t have much practical leverage if things don’t go their way.

And while I’m not suggesting that Epic would deliberately target smaller hospitals for indifferent service, giant institutions are likely to be its bread and butter for quite some time. It’s inevitable that when push comes to shove, Epic will have to prioritize companies that have spent hundreds of millions of dollars on its on-site product. Any vendor would.

All that being said, smaller hospitals are likely to overlook some of these problems if they can get their hands on such a popular EMR.  Also, as rockstar CIO John Halamka, MD of Beth Israel Deaconess Medical Center notes, Epic seems to be able to provide a product that gets clinicians to buy in. That alone will be worth the price of admission for many.

Certainly, vendors like MEDITECH and Cerner aren’t going to cede this market gracefully. But even as a Johnny-come-lately, I expect Epic’s cloud product do well in 2015.