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.For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manager 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, a role he recently repeated for a Council member.

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.

Making JustShowMeTheDoctorNetwork.com A Reality

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

Ok, that website really isn’t a project, but a website that has that functionality would be awesome. I recently had this problem. I was getting new health insurance and I wanted to know if our regular doctors would be part of the new insurance plan’s network. What a pain in the butt. Even the health insurance companies website made it difficult to know if they accepted the plan. The networks were named different than the insurance. Just plain ugly!

Turns out that Fred Trotter is doing what he can to help solve the “out of network” insurance game. Since it’s Fred Trotter you know it’s based on freeing the data. The post is well worth a read, but highlights why figuring out if your going to an in network or out of network provider is important and how the insurance companies are making it difficult to get access to this data.

Fred also points out a possible solution to a problem found in the text of the Notice of Benefit and Payment Parameters for 2016 (don’t you love how quickly the government works?). This new rule would essentially require insurance companies to provide an updated directory of providers and possibly requiring that they provide it in a machine-readable format. Seems like a small thing, but it would make a big difference.

However, this is the money quote from Fred about the government proposal above:

This would solve the problem. Anyone who wanted to could create a website that showed what plans any given provider accepted, would be able to easily do so.

But they key word here is “propose”. Insurance companies in this country benefit greatly from the confusion about in network and out of network, and so do some unethical healthcare providers. There will be lots of people who oppose this proposal.

I hope that I have made the case that this information needs to be open and machine readable. If your convinced, then you can find the comment page to support this policy here. If you disagree with us, and you still want to submit a comment, you can use this page.

Comments on this rule are due by 12/22 which doesn’t leave people much time to chime in. As someone who’s had to deal with this challenge recently, I hope that this rule is passed. I can’t wait for an entrepreneur to take this data and create a beautiful map overlay of the doctors in my network. Would make searching for a doctor in your insurance plan so much easier.

Communities Help Open Source Electronic Health Records Thrive (Part 3 of 3: Project Round-up)

Posted on December 16, 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://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.

This series examines the importance of community and what steps are being taken by open source projects in health IT to create communities around their projects. My previous posting covered VistA and its custodial organization, OSEHRA. The last article in this series covers some important projects in open source with very different approaches to building community.

In addition to VistA, the electronic health record with the most success in building community is OpenMRS, using a unique approach. The project has an unusual genesis. They didn’t come out of a technology center such as Silicon Valley, or a center of health research such as my own Boston. Instead, they were inspired by the Regenstrief Institute at Indiana University.

Getting only a small amount of attention in the United States, OpenMRS proved quite valuable in the developing regions of Africa, especially Rwanda. The U.S. developers realized right away that, for their software to be useful in cultures so far from Indiana, it would have to be understood and fully embraced by local experts.

Indeed, a number of accomplished software developers can be found in Rwanda and surrounding countries. The challenge to OpenMRS was to attract them to the goal of improving health care and to make work on OpenMRS easy.

OpenMRS not only trained developers in African countries to understand and adapt their software to local conditions, but mentored them into becoming trainers for other developers. The initial project to train Rwandan developers thus evolved, the local developers becoming competent to train others in neighboring countries.

In this way, the OpenMRS developers back in the U.S. opened up the project in a unique way to people on other continents. To be sure, the developers had a practical end: they knew they could not provide support to every site that wanted to install OpenMRS, or adapt it to local needs. But they ultimately created a new, intensely committed, international community around OpenMRS. Regular conferences bring together OpenMRS developers from far-flung regions.

The SMART platform is not an EHR itself, but an application programming interface (API) that its developers are asking EHR vendors to adopt. The pay-off for adoption will be that all compliant EHRs can interoperate, and a software developer can write a single app that runs on all of them. SMART was developed at Harvard Medical School with support from ONC. It now runs on top of FHIR, an HL7 project to provide a modern API giving access to all EHR data.

EHRs are not by any means the only community-building efforts in open source health IT. Another significant player is Open Health Tools, which came into being in recognition of the creative work being done by research firms, university professors, and others in various health IT areas.

OHT brings together a wide range of developers to build software for research, clinical work, and other health-related projects. It’s remarkably diverse, providing a meeting place for all projects interested in making health care technology work better. Although they have had problems finding financial support, they now solicit dues from interested projects and seem poised to grow.

For a while, OHT had grand visions of recruiting their members to contribute to a unified “framework” on which other software developers could build applications. This proved to be a bit too big a bite to chew, given the wide range of activities that go on in health IT. But OHT still encourages members to find common ground and make use of each other’s advances.

Aaron Seib, CEO of Open Health Tools, listed the main goals OHT has for its member developers: making communities discoverable, making their licensing intelligible, and addressing the intellectual property barriers that can constrain a project’s adoption. OHT also helps establish trust and connect the dots among the community members to multiply effects across member communities. Roger Maduro of Open Health News writes that OHT has played a critical role in building the open health ecosystem, including the VistA community.

Many other institutions also sense a need for community. A few years ago I spoke with John Speakman, who was working for the National Cancer Institute at the time. They had developed some software that was very popular among developers, but no one made any contributions back to the common software base, and the NCI wanted the users of the software to start taking responsibility for the tools on which they depended. He took on the task of building community, but left when he realized it was not going to take hold.

Among the problems was the well-known dependence of government agencies such as the NCI on contractors. Speakman points to an organizational and cultural gap between “the big Beltway Bandit companies (who will never use the code themselves to do biomedical science) over academic groups engaged in biomedicine.” He also thinks the NCI intervened too much in community activities, instead of letting community members work out disagreements on their own. “If the government is going to invest in the seeding of open source communities,” he says, “it has to (a) focus on releasing the data and see what folks do with it, and (b) use as light a hold as possible on how the communities run themselves.”

Athenahealth stands out among EHR vendors with its More Disruption Please program. There it is building an ecoystem of third-party tools that its customers can use as part of its cloud-based service. This goal is similar to that of the open source SMART platform, which is trying to get EHR vendors and other data stores to adopt a common API and thus make themselves more open to software developers.

Openness and community go together. Although the health IT field is slow to adopt both practices, some projects could be entering into a virtuous cycle where open source developers learn to appreciate the value of their communities, which in turn reward the most open projects with greater success.

Self Encrypting Drive Infographic

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

If you’re not encrypting your hard drives in healthcare, you’re just asking for a HIPAA penalty. If you want to learn more about the importance of encryption in general, check out this infographic:

Self Encrypting Drive Infographic

Who is Adopting EHRs and Why: ONC Turns up Some Surprises

Posted on 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://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.

A high-level view of the direction being taken by electronic health records in the U.S. comes from a recent data brief released by the Office of the National Coordinator. Their survey of physician motivations for adopting EHRs turns up some puzzling and unexpected findings. I’ll look at three issues in this article: the importance of Meaningful Use incentives and penalties, the role of information exchange, and who is or is not adopting EHRs.

Incentives and Penalties
The impact of the Meaningful Use bribes–sorry, I meant incentive payments–in the HITECH act are legendary: they touched off a mad rush to adopt technology that had previously aroused only tepid interest among most physicians, because they found the EHRs outrageously expensive, saw no advantage to their use, or just didn’t want to leave the comfort zone of pen and paper. The dramatic outcome of Stage 1, for instance, can be seen in the first chart of this PDF.

This month’s data brief reconfirms that incentives and penalties played a critical role during the period that Meaningful Use has been in play. In the brief’s Figure 3, incentives and penalties topped the list of reasons for adopting records, with nothing else coming even close (although the list was oddly chosen, leaving out credible reasons such as “EHRs are useful”).

The outsized role payments play is both strange and worrisome. Strange, because the typical $15,000 paid per physician doesn’t even start to cover the costs of converting from paper to an EHR, or even from one EHR to another. Worrisome, because the escalator (a favorite metaphor of former National Coordinator David Blumenthal) on which payments put physicians is leveling off. Funding in the HITECH act ends after Stage 3, and even those payments will be scrutinized by the incoming budget-conscious Congress.

In addition, Stage 2 attestations have been dismally low. Critics throughout the industry, smelling blood, have swooped in to call for scaling back, to suggest that meaningful use provisions be eased or weakened, or just to ask for a more concentrated focus on the key goal of interoperability.

The ONC knows full well that they have to cut back expectations as payments dry up, although penalties from the Center for Medicare & Medicaid Services can still provide some leverage. Already, the recent House budget has level-funded the ONC for next year. Last summer’s reorganization of the ONC was driven by the new reality. Recent initiatives at the ONC show a stronger zeal for creating and urging the adoption of standards, which would be consistent with the need to find a role appropriate to lean times.

Health Information Exchange
I am also puzzled by the emphasis this month’s data brief puts on health information exchange. Rationally speaking, it would make perfect sense for physicians to ramp up and streamline the sharing of patient data–that’s exactly what all the health care reformers are demanding that they do. Why should somebody ask a patient to expose himself to unnecessary radiation because an X-Ray hasn’t been sent over, or try to treat someone after surgery without knowing the discharge plan?

Actually, most physicians would. That’s how they have been operating for decades. Numerous articles find that most physicians don’t see the value of information exchange, and can profit from their ignorance of previous tests and treatments the patient has received.

And that’s probably why, after taking hundreds of millions of dollars from governments, the heavy-weight institutions called Health Information Exchanges have repeatedly thrown in the towel or been left gasping for breath. At least two generations of HIEs have come and gone, and the trade press is still searching for their value.

So I’m left scratching my head and asking: if doctors adopt EHRs for information exchange, are they getting what they paid for? Redemption may have arrived through the Direct project, an ONC-sponsored standard for a low-cost, relatively frictionless form of data exchange. Although the original goal was to make HIE as simple as email, the infrastructure required to protect privacy imposes more of a technical burden. So the ONC envisioned a network of Health Information Service Provider (HISP) organizations to play the role of middleman, and a number are now operating. According to Julie Maas of EMR Direct, nearly half a million people were using Direct in July 2014, and the number is expected to double the next time statistics are collected next February.

So far, although isolated studies have shown that HIEs improve outcomes and reduce costs, we haven’t seen these effects nationwide.

What Hinders Adoption
Some of the most intriguing statistics in the data brief concern who is adopting EHRs and what holds back others from doing so. The main dividing line is simply size: most big organizations have EHRs and most small ones don’t.

I have explored earlier the pressures of health care reform on small providers and the incentives to merge. Health care technology is a factor in the consolidation we’re seeing around the country. And we should probabaly look forward to more.

Americans have trouble feeling good about consolidation in any field. We’re nostalgic for small-town proprietors like the pharmacist in the movie It’s a Wonderful Life. We forget that the pharmacist in that movie nearly killed someone by filling a prescription incorrectly. In real life, large organizations can pursue quality in a host of ways unavailable to individuals.

One interesting finding in the data brief is that rural providers are adopting EHRs at the same rate as urban ones. So we can discard any stereotypes of country hick doctors letting teenagers set up the security on their PCs.

Lack of staff and lack of support are, however, major barriers to adoption. This is the last perplexing question I take from the data brief. Certainly, it can be hard to get support for choosing an EHR in the first place. (The Meaningful Use program set up Regional Extension Centers to partially fill the gap.) But after spending millions to install an EHR, aren’t clinicians getting support from the vendors?

Support apparently is not part of the package. Reports from the field tell me that vendors install the software, provide a few hours of training, and tip their hats good-bye. This is poetic justice toward physicians, who for decades have sent patients out weak and groggy with a prescription and a discharge sheet. Smart organizations set aside a major percentage of their EHR funding to training and support–but not everybody knows how to do this or has grasped the need for ongoing support.

I certainly changed some of my opinions about the adoption of EHRs after reading the ONC data brief. But the statistics don’t quite add up. We could use some more background in order to understand how to continue making progress.

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.

The Real Problem with ICD-10 Delay or ICD-10 #NoDelay

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

Today, AHIMA put together a really interesting Twitter campaign (they called a Twitter chat, but it wasn’t as much of a chat as a Twitter campaign in my book) where they tweeted about the need for no more delay to ICD-10. You can see what they did by checking out the #nodelay and #ICD10Matters hashtags. They were hitting a number of congressmen really hard. No doubt, their social media people will have seen these messages. We’ll see if that trickles up to the senators and representatives themselves.

On the opposite side is the AMA which is pushing congress for a 2 year delay to ICD-10. Modern Healthcare just published a story that the ICD-10 delay bill was “dead on arrival.” However, that seemed like a link bait headline. When you read the actual story, they suggest that the ICD-10 bill might be dead when it comes to the lame duck session of congress (now through the end of the year). However, it doesn’t address whether congress will choose to incorporate another ICD-10 delay into the SGR fix in 2015 like they did in 2014. That story is still waiting to be played out.

The real problem with all of this is a topic that we’ve discussed over and over here on EMR and EHR. It applied to meaningful use and EHR certification and now it applies just as well to the implementation of ICD-10. No doubt there are proponents and opponents on each side of the ICD-10 debate. Personally, I’ve seen both arguments and I think both sides have an interesting case to make. I don’t think the decision is as clear cut as either sides makes it out to be. If you delay ICD-10 many organizations will be hurt. If you move forward with ICD-10 many organizations will be hurt.

Uncertainty around ICD-10 is the real problem.

What’s worse than going ahead with ICD-10? Uncertainty about whether ICD-10 is going forward or not. What’s worse than delaying ICD-10? Uncertainty about whether ICD-10 is going forward or not. ICD-10 uncertainty is costing healthcare much more than either an ICD-10 delay or a hard and fast ICD-10 go live date.

The US government (yes, that includes all parts of the US government) needs to make a firm decision on whether ICD-10 should be implemented or not. If ICD-10 is going to be the US medical coding future, then we should bite the bullet and implement ICD-10 on schedule. Another delay won’t improve that implementation. If ICD-10 is not of value, then let’s offer some certainty and do away with it completely. Either way, the certainty will be more valuable than our current state of uncertainty.

I’ll admit that I’m not an expert on DC politics. However, I’ve wondered if there’s something the US government could do that would provide this certainty. In 2014, CMS had done everything they could do to provide that certainty. It turns out, they didn’t have the power to make such a promise. Congress undercut them and they got left with egg on their face.

Could Congress pass a bill that would either set the ICD-10 implementation in stone or banish ICD-10 forever? Would that provide healthcare organizations the certainty they need to plan for ICD-10? Or would they just be afraid that the President would do some executive order to delay ICD-10 again? Is there anything that can be done to communicate a clear message on ICD-10’s future?

My gut tells me that if ICD-10 isn’t delayed in the SGR Fix bill next year, then ICD-10 will probably go forward. You’ll notice that probably was the best I could say. Can anyone offer more certainty on the future of ICD-10? I don’t think they can and that’s the problem.

What I do know is that ICD-10 uncertainty is costing healthcare a lot!

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://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 cover some other open source projects dealing with communities.

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.