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!

Meaningful Use Stage 3 Success Could Rely On Vendors

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

Today I was reading a report on the Health IT Policy Committee’s review of pending Meaningful Use Stage 3 rules — which would ordinarily be as about as exciting as watching rocks erode — when something leapt out at me which I wanted to share with you, dear readers.

The overview, brought to us courtesy of Medical Practice Insider, noted that proposed plans for the Stage 3 rule would allow providers to attest in 2017, though attesting wouldn’t be mandatory until 2018. What this means, editor Frank Irving notes, is that it would be up to EMR vendors to be ready for providers wishing to attest a year early.

The folks overseeing this discussion, the Advanced Health Models and Meaningful Use Workgroup, seem (wisely) to have had their doubts that vendors could be relied upon to meet the 2017 deadline. At the session, workgroup members proposed a couple of alternative ways of addressing this timeline. One was to make the 2017 deadline go away, requiring instead that EMRs have full 2015 certification by 2018. Another was to allow optional attestation in 2017, but if need be, with 2014 EMR certification.

I don’t know about you, but this whole thing makes me nervous. By “whole thing,” I mean adjusting the rules to deal with the likely resistance vendors will exhibit to keeping their roadmap in synch with federal requirements.

After all, consider the history of EMR vendors’ relationship with providers. As we’ve noted, HHS has paid out about $30B in Meaningful Use incentives under HITECH without insisting that vendors provide interoperability. And what have EMR vendors done?  They’ve avoided developing shared standards for interoperability with an alacrity which amazes the eye.

In fact, some EMR vendors — including top contender Epic Systems — have been slapping providers with fees for data sharing (even if they’ve kind of dropped them for now), at prices which could leave them millions in the hole. If that isn’t dead opposite to what those in public policy hope to see happen, I don’t know what is.

Bottom line, if the good people overseeing Meaningful Use want to see Stage 3 accomplish good things, they’ll need to see to it that the new rules give regulators some leverage when it comes to controlling vendors.

As the whole sad interoperability saga has demonstrated, vendors will not take actions that advance health IT on their own. Unlike in other IT markets, where interoperability and meeting regulatory deadlines have been the signs of a winner, EMR vendors actually have strong incentives to ignore providers’ business imperatives.

With any luck, however, between tougher rules on Stage 3 and public pressure to achieve interoperability, EMR vendors will do the right thing.  They’ve certainly had long enough.

A “Collaborative Consult” Could Greatly Improve EMR Value

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

Over the past several years, EMRs have taken some steps forward. At least in some cases, analytics have improved, vendors have begun offering cloud or on-premise install versions of their products and user interfaces have even improved.

But one problem with EMRs that seems to be nearly unfixable is the need for providers to stare at an EMR screen, leaving patients to fidget uncomfortably while they wait for a bit of face-to-face contact and discussion. Sure, you’ll see scribes in hospital emergency departments, allowing ED docs to speak to patients without interruption, but in the outpatient settings where patients spend most of their time, the EMR screen is king.

Such a focus on the EMR display isn’t unreasonable, given the importance of the data being entered, but as critics have noted countless times, it does make it more likely that the provider will miss subtle clues as to the patient’s condition, and possibly end up offering lower-quality care than they would have if they had an old-fashioned computerless encounter.

I have long thought, however, that there’s a solution to this problem which would be helpful to both the physician and the patient, one which would literally make sure that patients and doctors are on the same page. I’m speaking of a new group of settings for EMRs designed specifically to let patients collaborate with physicians.

Such an EMR setting, as I envision it, would begin with a section depicting a dummy patient of the appropriate gender.The patient would touch the areas of the body which were causing them problems, while the doctor typed up a narrative version of the problem presentation. The two (patient and doctor) would then zoom in together to more specific descriptions of what the patient’s trouble might be, and the doctor would educate the patient as to what kind of treatment these different conditions might require.

At that point, depending on what condition(s) the doctor chose as requiring further study, lists of potential tests would come up. If a patient wanted to learn what these tests were intended to accomplish, they’d have the liberty to drill down and learn, say, what a CBC measures and why.  The patient would also see, where possible, the data (such as high cholesterol levels) which caused the doctor to seek further insight.

If the patient had a known illness being managed by the physician, such as heart disease, a tour through a 3-D visual model of the heart would also be part of the collaboration, allowing the doctor to educate the patient effectively as to what they were jointly trying to accomplish (such as halting heart muscle thickening).

The final step in this patient-doctor process would come with the system presenting a list of current medications taken by the patient, and if appropriate, new medications that might address any new or recurring symptoms the patient was experiencing.

The final result would come in the form of a PDF, e-mailed to the patient or printed out for their use, offering an overview of their shared journey. The doctor might have to spend a few minutes adding details to their notes after the patient left, but for the most part, the collaborative consult would have met everyone’s needs.

Now you tell me:  Why aren’t we doing this now?  Wouldn’t it make much more sense, and take much more advantage of the powerful desktops, tablets and smartphones we have, than having a provider stare at a screen for most of their visit with a patient?

HHS’ $30B Interoperability Mistake

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

Sometimes things are so ill-advised, in hindsight, that you wonder what people were thinking. That includes HHS’ willingness to give out $30 billion to date in Meaningful Use incentives without demanding that vendors offer some kind of interoperability. A staggering amount of money has been paid out under HITECH to incentivize providers to make EMR progress, but we still have countless situations where one EMR can’t talk to another one right across town.

When you ponder the wasted opportunity, it’s truly painful. While the Meaningful Use program may have been a good idea, it failed to bring the interoperability hammer down on vendors, and now that ship has sailed. While HHS might have been able to force the issue back in the day, demanding that vendors step up or be ineligible for certification, I doubt vendors could backward-engineer the necessary communications formats into their current systems, even if there was a straightforward standard to implement — at least not at a price anyone’s willing to pay.

Now, don’t get me wrong, I realize that “interoperability” is an elastic concept, and that the feds couldn’t just demand that vendors bolt on some kind of module and be done with it. Without a doubt, making EMRs universally interoperable is a grand challenge, perhaps on the order of getting the first plane to fly.

But you can bet your last dollars that vendors, especially giants like Cerner and Epic, would have found their Wilbur and Orville Wright if that was what it took to fill their buckets with incentive money. It’s amazing how technical problems get solved when powerful executives decide that it will get done.

But now, as things stand, all the government can do is throw its hands up in the air and complain. At a Senate hearing held in March, speakers emphasized the crying need for interoperability between providers, but none of the experts seemed to have any methods in their hip pocket for fixing the problem. And being legislators, not IT execs, the Senators probably didn’t grasp half of the technical stuff.

As the speakers noted, what it comes down to is that vendors have every reason to create silos and keep customers locked into their product.  So unless Congress passes legislation making it illegal to create a walled garden — something that would be nearly impossible unless we had a consensus definition of interoperability — EMR vendors will continue to merrily make hay on closed systems.  It’s not a pretty picture.

Customizable EMRs Are Long Overdue

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

EMRs can be customized to some extent today, but not that much. Providers can create interfaces between their EMR and other platforms, such as PACS or laboratory information systems, but you can’t really take the guts of the thing apart. The reality is that the EMR vendor’s configuration shapes how providers do business, not the other way around.

This has been the state of affairs for so long that you don’t hear too much complaining about it, but health IT execs should really be raising a ruckus. While some hospitals might prefer to have all of their EMR’s major functions locked down before it gets integrated with other systems, others would surely prefer to build out their own EMR from widgetized components on a generic platform.

Actually, a friend recently introduced me to a company which is taking just this approach. Ocean Informatics, which has built an eHealth base on the openEHR platform, offers end users the chance to build not only an EMR application, but also use clinical modules including infection control, care support, decision support and advanced care management, and a mobile platform. It also offers compatible knowledge-based management modules, including clinical modeling tools and a clinical modeling manager.

It’s telling that the New South Wales, Australia-based open source vendor sells directly to governments, including Brazil, Norway and Slovenia. True, U.S. government is obviously responsible for VistA, the VA’s universally beloved open source EMR, but the Department of Defense is currently in the process of picking between Epic and Cerner to implement its $11B EMR update. Even VistA’s backers have thrown it under the bus, in other words.

Given the long-established propensity of commercial vendors to sell a hard-welded product, it seems unlikely that they’re going to switch to a modular design anytime soon.  Epic and Cerner largely sell completely-built cars with a few expensive options. Open source offers a chassis, doors, wheels, a custom interior you can style with alligator skin if you’d like, and plenty of free options, at a price you more or less choose. But it would apparently be too sensible to expect EMR vendors to provide the flexible, affordable option.

That being said, as health systems are increasingly forced to be all things to all people — managers of population health, risk-bearing ACOs, trackers of mobile health data, providers of virtual medicine and more — they’ll be forced to throw their weight behind a more flexible architecture. Buying an EMR “out of the box” simply won’t make sense.

When commercial vendors finally concede to the inevitable and turn out modular eHealth data tools, providers will finally be in a position to handle their new roles efficiently. It’s about time Epic and Cerner vendors got it done!

ONC Annual Meeting – Who’s Going?

Posted on January 28, 2015 I Written By

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

ONC’s Agenda – February 2-3, Washington, DC

Next Monday, ONC holds its annual meeting in downtown DC. I’m going, one small advantage of living here. Here’s the agenda. To see day two, click on the agenda header.

I’m particularly interested in these topics:

  • Adverse event reporting,
  • Interoperability standards,
  • Meaningful Use program’s future, and
  • Usability.

Looking at the agenda, I should stay busy with one exception. There isn’t much on usability. The word’s only on the agenda once. Not a surprise since ONC has pretty much relinquished any role to the vendors.

How important do you think the ONC meeting and also the ONC run Healthdatapalooza now that meaningful use has kind of run its course? Will these two meeting gain steam and influence or will organizations start to go other places? I’ll be interested to watch that trend as I attend the event.

If you can’t attend, you can follow on various webcasts and twitter. If you do plan to attend, I’d love to see you there. To email me, click on my name in my profile blurb, or at carl@ehrselector.com.

The New Congressional Rider: Unique Patient ID Lemonade?

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

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

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

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

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

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

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

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

Gag Rule’s Replacement Language

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

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

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

NIST’s a Consensus Building Not a Rulemaking Agency

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

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

Looking Back at 2014: Thermidor for Health Care Reform?

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

As money drains out of health care reform, there are indications that the impetus for change is receding as well. Yet some bright spots in health IT remain, so it’s not yet time to announce a Thermidor–the moment when a revolution is reversed and its leaders put to the guillotine. Let’s look back a bit at what went right and wrong in 2014.
Read more..

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.

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

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.

Open Source Electronic Health Records: Will They Support Clinical Data Needs of the Future? (Part 2 of 2)

Posted on November 18, 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 part of this article provided a view of the current data needs in health care and asked whether open source electronic health records could solve those needs. I’ll pick up here with a look at how some open source products deal with the two main requirements I identified: interoperability and analytics.

Interoperability, in health care as in other areas of software, is supported better by open source products than by proprietary ones. The problem with interoperability is that it takes two to tango, and as long as standards remain in a fuzzy state, no one can promise in isolation to be interoperable.

The established standard for exchanging data is the C-CDA, but a careful examination of real-life C-CDA documents showed numerous incompatibilities, some left open by the ambiguous definition of the standard and others introduced by flawed implementations. Blue Button, invented by the Department of Veterans Affairs, is a simpler standard with much promise, but is also imperfectly specified.

Deanne Clark, vxVistA Program Manager at DSS, Inc., told me that VistA supports the C-CDA. The open source Mirth HIE software, which I have covered before, is used by vxVistA, OpenVista (the MedSphere VistA offering), and Tolven. Proprietary health exchange products are also used by many VistA customers.

Things may get better if vendors adopt an emerging HL7 standard called FHIR, as I suggested in an earlier article, which may also enable the incorporation of patient-generated data into EHRs. OpenMRS is one open source EHR that has started work on FHIR support.

Tolven illustrates how open source enables interoperability. According to lead developer Tom Jones, Tolven was always designed around care coordination, which is not the focus of proprietary EHRs. He sees no distinction between electronic health records and health information exchange (HIE), which most of the health IT field views as separate functions and products.

From its very start in 2006, Tolven was designed around helping to form a caring community. This proved useful four years later with the release of Meaningful Use requirements, which featured interoperability. APIs allow the easy development of third-party applications. Tovlen was also designed with the rights of the patient to control information flow in mind, although not all implementations respect this decision by putting data directly in the hands of the patient.

In addition to formats that other EHRs can recognize, data exchange is necessary for interoperability. One solution is an API such as FHIR. Another is a protocol for sending and receiving documents. Direct is the leading standard, and has been embraced by open source projects such as OpenEMR.

The second requirement I looked at, support for analytics, is best met by opening a platform to third parties. This assumes interoperability. To combine analytics from different organizations, a program must be able to access data through application programming interfaces (APIs). The open API is the natural complement of open source, handing power over data to outsiders who write programs accessing that data. (Normal access precautions can still be preserved through security keys.)

VistA appears to be the EHR with the most support for analytics, at least in the open source space. Edmund Billings, MD, CMO of MedSphere, pointed out that VistA’s internal interfaces (known as remote procedure calls, a slightly old-fashioned but common computer term for distributed programming) are totally exposed to other developers because the code is open source. VistA’s remote procedure calls are the basis for numerous current projects to create APIs for various languages. Some are RESTful, which supports the most popular current form of distributed programming, while others support older standards widely known as service-oriented architectures (SOA).

An example of the innovation provided by this software evolution is the mobile apps being built by Agilex on VistA. Seong K. Mun, President and CEO of OSEHRA, says that it now supports hundreds of mobile apps.

MedSphere builds commercial applications that plug into its version of Vista. These include multidisciplinary treatment planning tools, flow sheets, and mobile rounding tools so doctor can access information on the floor. MedSphere is also working with analytic groups to access both structured and unstructured information from the EHR.

DSS also adds value to VistA. Clark said that VistA’s native tools are useful for basic statistics, such as how many progress notes have not been signed in a timely fashion. An SQL interface has been in VistA for a long time, DSS’s enhancements include a graphical interface, a hook for Jaspersoft, which is an open source business intelligence tool, and a real-time search tool that spiders through text data throughout all elements of a patient’s chart and brings to the surface conditions that might otherwise be overlooked.

MedSphere and DSS also joined the historical OSEHRA effort to unify the code base across all VistA offerings, from both Veterans Affairs and commercial vendors. MedSphere has added major contributions to Fileman, a central part of VistA. DSS has contributed all its VistA changes to OSEHRA, including the search tool mentioned earlier.

OpenMRS contributor Suranga Kasthurirathne told me that an OpenMRS module exposes its data to DHIS 2, an open source analytics tool supporting visualizations and other powerful features.

I would suggest to the developers of open source health tools that they increase their emphasis on the information tools that industry observers predict are going to be central to healthcare. An open architecture can make it easy to solicit community contributions, and the advances made in these areas can be selling points along with the low cost and easy customizability of the software.