Is a New World of Interoperability-Fueled Clinical App Development Around the Corner? | Mark Hagland | Healthcare Blogs Skip to content Skip to navigation

Is a New World of Interoperability-Fueled Clinical App Development Around the Corner?

May 31, 2017
| Reprints
An op-ed in the May 18 New England Journal of Medicine speaks to interoperability-related challenges and opportunities

I read with fascination a “Perspective” column in the May 18 edition of The New England Journal of Medicine, written by Kenneth D. Mandl, M.D., M.P.H., and Isaac S. Kohane, M.D., M.P.H., medical informaticists practicing at Boston Children’s Hospital and at the Department of Biomedical Informatics at Harvard Medical School, respectively.

Entitled “A 21st-Century Health IT System—Creating a Real-World Information Economy,” the op-ed was both broadly comprehensive and also of sufficient granularity and practical depth, on the subject of how federal healthcare officials can compel forward a path forward towards the interoperability of the APIs (application programming interfaces) that collectively offer a way forward on clinical IS interoperability for U.S. (and international) healthcare.

The authors frame their “Perspectives” op-ed by noting that, while the HITECH (Health Information Technology for Economic and Clinical Health) Act of 2009 spurred forward the adoption of EHRs (electronic health records) on the part of hospitals and physicians, “Eight years later, however, the U.S. healthcare system still doesn’t have a usable IT engine that can generate high-quality data, a restriction that may impede progress toward the use of real-world evidence to advance treatment and research. D

Drs. Mandl and Kohane state that they are cheered by the inclusion in the 21st Century Cures Act, passed X, of “a provision that could transform hundreds of existing EHR products certified under the meaningful use program into a coherent platform for innovation and transformation, despite the systems’ nonmodular design and disparate data formats. The new law,” they note, “requires that certified health IT products  have an application programming interface (API) that allows health information to be accessed, exchanged, and used ‘without special effort.’ Such an interface,” they note, “could allow third-party developers to create functionality  that interacts and integrates with other systems in predictable and standardized ways.”

Numerous other commentators have made note of this provision in the 21st-Century Cures Act. Indeed, at a time of disharmony and legislative gridlock in Washington, the passage of 21st-Century Cures—which of course covered a very broad base of areas of endeavor, healthcare IT being only one relatively small slice of its whole—represents a breakthrough that could help transform how healthcare IT evolves forward in the U.S. in the next decade.

But what Drs. Mandl and Kohane have to say is particularly interesting and apropos. “Going forward,” they write, “the API provision in the 21st-Century Cures Act could be leveraged to powerful effect. First of all, if the API is open and standardized across systems, a new form of interoperability will emerge: substitutability. Substitutability would mean that apps could be added to or deleted from an EHR just as they can be on a smartphone—a step that would reflect a shared commitment to the transferability  of healthcare data and knowledge.”

And here’s where the authors get granular. “A uniform open, standardized healthcare API would allow a given app to run on any EHR,” the authors write. “This approach would produce game-changing economies of scale and starkly contrast with current conditions, in which nearly all innovative applications require expensive, time-consuming, custom integrations to connect to EHRs. Physicians and patients would have access to a wide selection of software that could connect to their existing systems. Innovators would have a marketplace where they could compete on quality, price, value, and user experience without mustering the idiosyncrasies of each EHR brand. EHRs would have become commodity components in a large platform that would include other transactional systems and data warehouses running myriad apps, and apps could have access to diverse sources of shared data beyond a single health system’s records.”

What’s more, very importantly, the authors note that, if that level of interoperability were achieved, “Research, regulatory, and public health organizations could both access data obtained at the point of care and deliver services to physicians and patients through substitutable apps that connect to EHRs, as developers create resources for an ‘app store’ for health and research. Substantial progress has been made toward these goals, but they haven’t been achieved on a system-level scale,” they note.

Indeed, these observations speak to a core barrier that the developers of APIs have faced in U.S. healthcare until now—how to overcome the challenge of universality, or as these authors frame it, substitutability.

In fact, this situation reminds me of my readings in history, in particular, the early history of consumer telephone use and the early history of automobile development. Both industries suffered from barriers of particularity. Years ago, I watched a documentary on PBS that described the development of early local phone systems, and was fascinated. The PBS documentary focused on what happened in Kansas City, where consumers rushed to get home telephone service, but were disappointed to discover that they could not in any way be connected with anyone subscribing to a different telephone company’s service; and there were four operating in Kansas City. So that meant that your sister, your neighbor, your doctor, your housepainter, your second-cousin-once-removed, could all be on one of four different, non-connected systems. Naturally, this led to tremendous customer satisfaction—and ultimately resulted in the emergence and consolidation of the Bell Telephone system.

Meanwhile, back in the 21st century, it was very worthwhile to interview Alistair Erskine, M.D., CMIO of the Danville, Pa.-based Geisinger Health System, as I prepared one of our Top Ten Tech Trends for our March issue this year. The experience that Erskine and his colleagues had recently with developing and then attempting to commercialize an app that was FHIR-compliant—that is to say, compliant with the FHIR (Fast Healthcare Internet Resources) standard—demonstrates both the upside and the downside of the current FHIR-facilitated landscape, he says. Erskine and his colleagues invested time, effort, and funding into the creation of a rheumatology application. “We proved that we could use it on several different platforms,” he reports. “We tried to commercialize it, but got nowhere. There were two key problems. One, the various EHRs [electronic health records] weren’t really ready for a production-based mechanism. There was a lot of work the client had to do on their end to make it work; it wasn’t plug-and-play. Instead,” he says, “it was, build to plug, and do a lot of work to play. And while the app did something useful and helped us to take care of rheumatology arthritis patients, the colors, the buttons, and the feel weren’t harmonious with existing EMRs. So the informaticians and clinicians weren’t comfortable with having to teach end-users to use this.”

Erskine says that Geisinger’s experience with the rheumatology-focused app points to a broad weakness in the current development landscape. “How do you take all these disparate apps and make them work with the natural user interfaces that end-users are used to?” he asks. “Unlike an app on an iPhone, each download of an app using SMART on FHIR requires BA [business associate] agreements, a whole series of architectural reviews with a client, and a whole series of contractual arrangements. So there really was a missing app store where you could say everything in that app store is already vetted, is safe, is free from hacking, is something that I can trust.” And while a small number of the biggest EHR vendors, including Cerner Corporation, McKesson Corporation, and Epic Health Systems, have built platforms on which developers can create FHIR-compliant apps, there is not yet an easy pathway for the development of apps by organizations like Geisinger Health, that will readily be accepted by practicing physicians and other clinicians. Indeed, based on how their experiment turned out, the Geisinger folks made a course correction in their initiative. “We found that the end-user experience tends to be different from EHR to EHR, so we said, let’s let the EHR vendor control the graphical user interface; we can use FHIR to augment the data sitting in the EHR,” Dr. Erskine told me. “So if I use my big data platform to identify patients with kidney disease who should have that marked on their problem list, I can alert my EMR to alert the end-user physician.” It’s not an ideal situation, he concedes. “It would have been nice, if I’m a rheumatologist, to go to this pre-approved app store and download a few apps that would work for me as a clinician. That would have been nice if that had been feasible. So the reluctance of the vendors to have something user-ready and the contractual issues, etc., those are all reasons it hasn’t flourished yet.”

It seems to me that the experience that Dr. Erskine and his colleagues have had at Geisinger speaks to a really, really basic issue here—the “recreating the wheel” problem, if I may. There’s simply got to be a better way to create broad platforms that can lead to the creation of large numbers of interoperable, useful clinical apps, than how it’s been done until now. And honestly, even the very smartest and most innovative clinicians and clinical informaticists simply aren’t going to spend countless hours working on the technical steps around creating innovative APIs.

Indeed, there are very, very many clinical informaticists eager to create truly useful apps, apps that could potentially transform patient care delivery in key areas. For example, last year, I met with Shivdev Rao, M.D., a cardiologist at the vast UPMC health system in Pittsburgh. Dr. Rao enjoyed sharing with me his work collaborating with fellow clinical informaticists on an app that could prove quite useful to fellow practicing cardiologists. As he told me in an interview, “A little app I’m looking at right now on my smartphone, tells me when any one of my patients is in the emergency department, is admitted as an inpatient, or is discharged. Where did this idea come from? Well, historically, what would happen to me is that I’d end up in clinic and see ten patients who’d already been in the hospital, and had had their cardiac meds had been changed without informing me. On the surface, this appears to be a very simple application, but behind the scenes, making it successful requires connecting a lot of dots between our inpatient system, our outpatient system, and our ADT system, pulling demographic data on these patients; and it requires pulling a care team together around these patients. So I now get actionable notifications. I can choose to call the ED, the patient, or any other doctors on the team.”

It was exciting to hear about the development of that app for cardiologists; and it wasn’t surprising to me in any way that UPMC, a pioneering organization in the arena of applied clinical informatics, has been funding app development through its UPMC Enterprises division, which is actively working on apps and solutions that could change patient care, and working to move as many new solutions towards commercialization as possible. Nor is UPMC alone in this; Cleveland Clinic, Mayo Clinic, Intermountain Healthcare, and Geisinger Health System, among other large integrated health systems, are doing the same, funding healthcare IT tech beds, and getting very practical in moving forward to close gaps around useful clinical apps, by engaging physicians and other clinicians within their organizations in developing their own.

And that’s the arena in which we can expect some of the next breakthroughs to take place in this very important sphere. As Drs. Mandl and Kohane put it, “If we make it our goal for a given app to be able to run on any EHR in the U.S. healthcare system, we minimize the risk that the 21st-Century Cures Act will produce only local successes and scores of balkanized, disparate apps.” What’s more, they write, “We also maximize the opportunity for the United States to become a leader in developing new healthcare applications for clinicians and patients with varying needs and ensuring the safe and timely flow of information for patients, care providers, and researchers.”

I have real hope that things will move forward along these different dimensions, since really, they need to. This is a tremendous example of where federal healthcare IT policy, vendor solutions evolution, changes in clinical practice, including the shift towards care management and population health management, and the broader healthcare policy environment, all intersect. Consider how important the app that Dr. Rao and his colleagues at UPMC, could be, for cardiologists who are given more direct accountability for certain specific elements of patient flow and transitions of care. One can easily imagine numerous similar scenarios, U.S. healthcare system-wide.

So let’s hope that what Drs. Mandl and Kohane have envisioned, moves towards practical reality. The U.S. healthcare system—and ultimately, healthcare systems around the world—could benefit immensely from a level of interoperability that turbocharges the development of apps that could work with any EHR—really, we could be on the doorway to a new world.




The Health IT Summits gather 250+ healthcare leaders in cities across the U.S. to present important new insights, collaborate on ideas, and to have a little fun - Find a Summit Near You!


Where is the Information Blocking Rule? Health IT Now Criticizes Missed Deadline

December 17, 2018
by Heather Landi, Associate Editor
| Reprints

Industry group Health IT Now, a coalition of healthcare and technology companies, responded today to the Trump Administration's latest missed deadline for publication of a proposed information blocking rule as required under the 21st Century Cures law.

The proposed rule was sent by the Office of the National Coordinator for Health IT (ONC) to the Office of Management and Budget (OMB) on September 17, 2018, setting off a 90-day timeline for the agency to complete its review; a period which was now expired without publication of a proposed rule, according to Health IT Now.

The onus to publish the regulation falls on ONC, the health IT branch of the federal government that is tasked with carrying out specific duties that are required under the 21st Century Cures Act, which was signed into law in December 2016. Some of the core health IT components of the Cures legislation include encouraging interoperability of electronic health records (EHRs) and patient access to health data, discouraging information blocking, reducing physician documentation burden, as well as creating a reporting system on EHR usability.

The information blocking part of the law has gotten significant attention since many stakeholders believe that true interoperability will not be achieved if vendors and providers act to impede the flow of health data for proprietary reasons.

“Now, more than two years after 21st Century Cures was enacted, patients and providers are still without an information blocking rule - undermining the intent of the law,” Health IT Now officials stated.

ONC has delayed regulation around information blocking a few times already, previously stating that the rule would be released in April then revising its timeline to September, before finally submitting the rule to OMB on September 17th.  

As previously reported by Healthcare Informatics Managing Editor Rajiv Leventhal, during an Aug. 8 episode of the Pulse Check podcast from Politico, National Coordinator for Health IT Donald Rucker, M.D., said that the rule is "deep in the federal clearance process." And even more recently, a bipartisan amendment to the U.S. Senate's Department of Defense and Labor, Health and Human Services, and Education Appropriations Act for Fiscal Year 2019 includes a requirement for the Trump administration to provide Congress with an update, by September 30.

“It is stunning that, more than two years after 21st Century Cures became law, we are still waiting on regulators to actually do what the law says,” HITN Executive Director Joel White said in a statement issued Monday. “Patients and providers have looked on with disappointment as the administration blows through one missed deadline after another for publicly releasing a proposed information blocking rule. It is time to say 'enough.' By continuing to slow walk these regulations, the administration is adding to uncertainty in the marketplace and is quickly reaching a point whereby it will be in obvious defiance of the spirit of the Cures law.”

White further stated, “Lawmakers who worked doggedly to get this landmark, bipartisan bill across the finish line should be incensed by the way that bureaucratic delays have weakened their signature achievement. This holiday season, the best gift that OMB could give consumers would be an expedited completion of its review and the public release of a robust information blocking rule. In the meantime, we are hopeful that industry stakeholders will not delay interoperability initiatives as a result of the ambiguity created by these continued delays.”

It is not the first time that the Health IT Now executive director has been publicly critical of the Trump administration for not yet publishing any regulation on information blocking. In an op-ed published September 8 in STAT, White wrote, “More than 600 days after the enactment of the Cures Act, not a single regulation has been issued on information blocking.” White added in frustration, “Health IT Now has met with countless officials in the Trump administration who share our commitment to combat information blocking. But those sentiments must be met with meaningful action.”

More From Healthcare Informatics


Intermountain CMIO Stan Huff on the Need for Greater Interoperability: “We’re Killing Too Many People”

December 6, 2018
by Rajiv Leventhal, Managing Editor
| Reprints
About 250,000 people die per year due to preventable medical errors, and that’s the biggest motivator there is for more advanced interoperability, says one clinical IT leader

Stan Huff, M.D., chief medical informatics officer (CMIO) at the Salt Lake City, Utah-based Intermountain Healthcare for the past 31 years, has long been a top leader in his field. Working on the leadership team for a health system like Intermountain and serving as a co-chair of the HL7 Clinical Information Modeling Initiative (CIMI), while also having been a former member of the ONC Health IT Standards Committee, Huff has a wealth of knowledge coming from both provider- and standards-focused perspectives.

Huff, who represented Intermountain at a White House meeting on interoperability this week, recently chatted with Healthcare Informatics about all things interoperability, including the different types of data exchange that exist today, the greatest barriers, and how potential pending regulations could shake up the landscape. Below are excerpts from that discussion.

When you look at the interoperability landscape today, how bullish are you on where things stand, broadly speaking? Or rather than bullish, are you more concerned?

I don’t know if I am bullish or not, but I think we are making progress—and it’s significant progress. There is an incredible amount of work to be done. I’m not concerned at the progress; I am happy, but mindful of how much work is left to do to really reap the benefits that people are hoping for.

You’re currently a co-chair of the HL7 Clinical Information Modeling Initiative while also having been a member of former the ONC Health IT Standards Committee. How important is it to figure out the issues around standards before things can progress?


Advancements in Healthcare: Interoperability, Data Exchange, and More

Micky Tripathi, President and Chief Executive Officer of the Massachusetts eHealth Collaborative, is one of the most well-informed and well-respected healthcare IT leaders in the U.S. Tripathi has...

I wish it had a higher priority. Most of the time when people are talking about interoperability now, they are thinking about caring for an individual patient and thinking about sharing information between different systems that have information on that patient. They are usually thinking about EHR [electronic health record]-to-EHR for patient care—they have a very focused idea.

But there are other dimensions. There is interoperability relative to public health, meaning how we share data from an organization to a public health [entity] so that we understand what’s going on with a whole population relative to a particular disease.

There is also research interoperability, so we can share data that’s coming from research activities. And closely related to that is interoperability of clinical trial data and all of the randomized controlled trial data that comes with that.

Then there is interoperability that comes from devices and data coming from devices, which is a whole field onto itself. So you have to be careful when you talk about interoperability. This is one axis of interoperability, in that it has to do with the scope of systems you are communicating with.

The other axis of interoperability has to do with how truly interoperable you are, and there are different levels there as well. One level is the interoperability you get with the HL7 version 2 [standard], where you have a structure and people know how to send messages between systems. And there is a lot of negotiation that happens when you set up an HL7 version 2 interface to say what terminology you are using, and if you send something as two fields or one field. There is a lot that goes on there and that’s helped quite a bit when you talk about HL7 FHIR [Fast Healthcare Interoperability Resources]—it has a more defined structure and has more things specified about terminology use.

And then you can get an even better of interoperability if you are using the Argonaut [Project] profiles. But even at that Argonaut profile level, you aren’t plug-and-play interoperable. There still is ambiguity in the Argonaut definitions that lead to different implementations by different companies and organizations.

The highest level is what I would call “plug-and-play” where this no bilateral negotiation around terminology or anything like that. The standard is explicit enough so that it could be tested for conformance and you can say whether a given system is conformant or not, and the data can be used in the way it was intended. We don’t have any plug-and-play interoperability to speak of right now, and that’s what I’m trying to shoot for.

One of three biggest motivators for me is patient safety. There is really good and convincing data that shows we are killing 250,000 people per year due to preventable medical errors. And that won’t be solved by “zero harm” programs, or by “sort of” interoperable systems. In the end, the “sort of” interoperable systems means that a person still has to look at things and make a judgment. And people are not perfect information processors. So you need a situation where the data is explicit enough where I can write rules that prevent the death or improper treatment of patients.

And we are not at that level yet. How urgent is it? I think it’s incredibly urgent and you can make an argument that it’s more important than lots of other things we’re spending money on that would have less of an impact on patient care. I work in this area, so yes, I am biased.

But I’m persuaded that it’s worth an investment, and to get to where I want to get to will not be easy. This won’t be something where you make one $20 million investment and then it’s done; it will take five or 10 years, and you will make incremental progress over that period of time. Think of it like a military campaign or a crusade, because it’s that type of timeframe and scale where you need planning and infrastructure to really accomplish what we want to do in the end—which is save lives, decrease the cost of care, and reduce the burden of clinicians.

Many folks believe that until the business incentives change, stakeholders will not be incentivized to be open with their systems. Do you agree with this and how much incentive exists today?

There isn’t a whole lot of incentive yet. If the patient care and safety issues were sufficient enough incentives, then this would have been solved a long time ago because those incentives have been there. People know and understand that we’re not caring for patients in the best way possible. And it’s the financial and proprietary considerations that keep us from doing that, ultimately.

We have to be careful [with incentives] though, because there are unexpected consequences. Going back to when I was on the HIT Standards Committee, we thought that we were doing useful and good for U.S. healthcare when we set up the meaningful use measures. And while meaningful use solved the EHR adoption issue, what it taught people was how to manage measures but not manage quality.

People became incredibly good when it came to managing the measures to get paid and to meet the qualifications, but I don’t think anyone would assert that those things improved the quality of care in any measurable way. So I think we didn’t meet the goal that we were shooting for—providing better quality care at a lower cost.

The ONC annual conference took place last week, and there seemed to be significant conversations around pending regulations such as possibly making interoperability a requirement to stay in Medicare and prohibiting information blocking. How does all of this land for you?

I welcome the change; it’s a good as thing you move from meaningful use to promoting interoperability. What I don’t know is if these specific [rules] being proposed are going to accomplish what [we want]. We thought we were doing the right things back when we were doing meaningful use.

At a high level, I would agree that it would be wonderful to require interoperability as a requirement for Medicare participation. But it’s undefined. When talking about the dimensions and these things, there has to be an understood and a useful level for the interoperability that’s required. But I haven’t seen the details to know whether what’s being asked for is both achievable and valuable if it were to be achieved. But I do agree with the [overall] direction.

Intermountain is often at the forefront of health and health IT initiatives such as its sponsorship of the Opioid Community Collaborative. How can these learnings be shared so they can improve the digital healthcare ecosystem?

The thing I try to emphasize to people is that if you look at what we are doing, and you take it in aggregate across the country—the things people are applying decision support to—it’s a tiny part of what we could do. And the reason for that is we don’t have interoperability. You can create a good program at Intermountain, or at Kaiser Permanente, or at Mayo Clinic, but the only place it works well is where it was developed. You cannot move it. If you move it, you have to recreate it. Until you have interoperability, I can’t write a rule that works on top of a Cerner system and also on an Epic system, or for that matter works on two different Cerner implementations. This cannot happen until you have those platforms supplying APIs so I can hook my decision support up to their system without rewriting all of the logic in a different technology platform.

So we are doing good things, and want to continue to do good things, but wouldn’t it be wonderful if what we did, or what the University of Utah is doing with opioids, can be directly moved and used, in the same way people can buy apps for their iPhones in the app store, or any other platform.

The realization is we might be doing 150 things at Intermountain in terms of decision support applications, but there is an opportunity to do 5,000 things, and we will never get to those 5,000 things unless we get to an interoperable platform so that when knowledge is created it can be shared. That’s my real emphasis behind interoperability.


Related Insights For: Interoperability


KLAS: EHR Vendors Making Significant Progress with CommonWell, Carequality Connection

December 4, 2018
by Heather Landi, Associate Editor
| Reprints
While most EHR vendors have connections to the national network, only athenahealth and Epic customers have connected en masse, KLAS reports
Click To View Gallery

With the establishment of connectivity between CommonWell and Carequality, announced back in August, as well as other interoperability advancements by electronic health record (EHR) vendors, the ability to exchange patient records is within the reach of most acute care or clinic-based provider organizations, regardless of size or financial situation, according to a new report from Orem, Utah-based KLAS Research.

In the report, “Interoperability: Real Progress with Patient Record Sharing Via CommonWell and Carequality,” KLAS researchers note that since the last KLAS report on interoperability, which was published in March 2018, the acute care/ambulatory EHR market has taken critical steps forward in sharing data via national networks. The most notable advancements include the establishment of the CommonWell-Carequality link, Meditech’s initial connection to CommonWell, and notable Carequality adoption among NextGen Healthcare customers, according to KLAS researchers.

Most of the prevalent acute care/ambulatory EHR vendors are connected to the national framework, marking significant progress for interoperability, according to KLAS researchers. The report findings come a few weeks after CommonWell and Carequality announced that the connection to the Carequality framework was “generally available.” Cerner and Greenway Health successfully completed a focused rollout of the connection with a handful of their provider clients, who have been exchanging data daily with Carequality-enabled providers, CommonWell officials said.

In August, CommonWell Health Alliance and Carequality announced initial connectivity, which is the beginning of a broader effort to increase health data exchange nationwide, and builds on an announcement made almost two years ago. In December 2016, CommonWell and Carequality announced connectivity and collaboration efforts with the aim of providing additional health data sharing options for stakeholders. Officials said that the immediate focus of the work between Carequality and CommonWell would be on extending providers’ ability to request and retrieve medical records electronically from other providers. In the past year and a half, teams at both organizations have been working to establish that connectivity.

Now, since the connection went live in July, officials noted that CommonWell-enabled providers have bilaterally exchanged more than 200,000 documents with Carequality-enabled providers locally and nationwide, as reported by Healthcare Informatics in November.


Advancements in Healthcare: Interoperability, Data Exchange, and More

Micky Tripathi, President and Chief Executive Officer of the Massachusetts eHealth Collaborative, is one of the most well-informed and well-respected healthcare IT leaders in the U.S. Tripathi has...

CommonWell, an alliance formed five years ago, operates a health data sharing network that enables interoperability using a suite of services aiming to simplify cross-vendor nationwide data exchange. Major vendors connecting to CommonWell include athenahealth, Cerner, CPSI, eClinicalWorks, Greenway Health and Meditech.

Meanwhile, Carequality, an initiative of The Sequoia Project that launched about a year later, is a national-level, consensus-built, common interoperability framework to enable exchange between and among health data sharing networks. Vendors using Carequality include athenahealth, Epic, eClinicalWorks and NextGen Healthcare. Nearly all major EHR vendors have aligned with one or both of these options, according to KLAS.

Together, CommonWell members and Carequality participants represent more than 90 percent of the acute EHR market and nearly 60 percent of the ambulatory EHR market. Today, more than 15,000 hospitals, clinics, and other healthcare organizations have been actively deployed under the Carequality framework or CommonWell network, officials attest.

This latest KLAS interoperability follows a report back in March in which KLAS researchers positioned that the CommonWell Health Alliance’s interoperability efforts were hindered by a lack of provider adoption and its interoperability services currently lacked value. However, when CommonWell and Carequality eventually connect, “instant value” will be created for users, KLAS researchers attested in that report.

Currently, Epic is not a member of CommonWell, despite other major EHR vendors pushing them in that direction. Back in 2015, athenahealth CEO Jonathan Bush famously tweeted to Epic’s CEO Judy Faulkner that his company would pay for Epic to join.

Indeed, KLAS reported in March that CommonWell will likely see a significant adoption increase with a solid Carequality connection. “Since its launch five years ago, the tendency to over-market the level of adoption of CommonWell has created apprehension and a lack of trust among potential participants and prompted this report, showing a snapshot of providers’ success,” the researchers said in the March report. KLAS researchers also claimed that when CommonWell connects to Carequality, “the entire Epic base will become available, creating instant value for most areas of the country.”

Following the publication of that report, CommonWell’s Executive Director Jitin Asnaani, in an exclusive interview with Healthcare Informatics, defended his organization’s mission and attested that the network is continuing to grow and prove its worth.

Asnaani also critiqued the KLAS report’s claim that vendors such as athenahealth and Epic give their customers a head start by enabling plug-and-play data sharing via Carequality. Asnaani called this specific critique “totally bogus,” asserting that the quality of data sharing is dependent on the vendors rather than dependent on CommonWell or Carequality.

KLAS Assessment on the Progress of CommonWell-Carequality Connection

In this latest report, KLAS researchers focused specifically on the progress EHR vendors have made in sharing patient records via the standardized (plug-and-play) networks of CommonWell and Carequality.

KLAS researchers assert that this focus is important because the “plug-and-play” option is the “only option” that allows provider organizations “avoid significant costs, delays, and organizational workload.”

KLAS also acknowledged that “virtually all major EMR vendors can successfully share patient records through the traditional point-to-point connections (a costlier approach in terms of time, resources, ongoing maintenance, and money), local HIEs (health information exchanges) and direct exchange (where records are manually sent to other providers).”

Referring to the CommonWell-Carequality connectivity as the “connection heard round the U.S.,” KLAS researchers contend that this connection should be “key in driving value and opening the floodgates so that any provider organization that desires to can exchange patient records with relative ease and little cost.” KLAS plans to measure the impact of this sharing in a 2020 interoperability report.

According to the report, this fall, two CommonWell-connected Cerner organizations tested and validated the ability to connect with Epic sites via Carequality. “Their initial reports are that the connection enables data sharing with critical partners otherwise out of their reach and adds tremendous value to their existing CommonWell exchange. The Epic sites involved indicate that they also are able to see and consume data via the new connection,” KLAS researchers wrote.

In a blog post, KLAS researcher Corey Tate, the author of the latest KLAS report, reiterated the value of the CommonWell-Carequality connection with regard to the availability of Epic data to provider organizations who connect. “Access to the Epic data is exactly what was talked about by the initial sites that tested the CommonWell connection to Carequality. Ironically enough, Epic’s intra-operability, which was initially dismissed, will likely be the catalyst that pulls widespread patient-record sharing forward. “

Currently, all but two of the other major EHR vendors—athenahealth, Cerner, CPSI, eClinicalWorks, Epic, Greenway Health, MEDITECH, NextGen Healthcare, and Virence Health (formerly GE Healthcare)—have customers connecting, according to KLAS. At this point, Allscripts and MedHost have yet to connect to CommonWell or Carequality. However, Allscripts recently announced more solidified plans to have their Carequality connection ready in Q1 2019 and to then roll it out in product updates throughout the year, according to KLAS. MedHost has been aligned with CommonWell since 2014 but has yet to have any live connections, KLAS researchers state.

While all of these vendors have connections to this national network, only athenahealth and Epic customers have connected en masse, according to Tate, in his blog post. “Each vendor has more than 90 percent of their customers connected. Cerner is next at around 35 percent. Many other vendors’ customer bases are just getting started,” Tate wrote.

“Epic and athenahealth have near complete uptake among their customers, allowing them to work on the next steps for interoperability, such as fine-tuning usability and increasing value for clinicians,” KLAs researchers wrote in the latest report. The researchers noted that plug-and-play sharing is “virtually invisible and automatic” for athenahealth and Epic customers, and “both vendors remove the big obstacles” to providers’ success.

KLAS researchers also highlight Epic’s and athenahealth’s approach to facilitating participation, via an opt-out approach, and removing governance barriers, via predetermined handling of outside data. The researchers contend that this indicates that “regardless of customer size, vendors can facilitate widespread adoption if they choose.”

NextGen Healthcare and eClinicalWorks show the most notable progress in connecting to the national framework, according to KLAS. Since NextGen Healthcare made their bidirectional connection available in Q1 2018, customers have rapidly taken up connections to Carequality. “With 80 customers connected, there is still much room for additional uptake—though NextGen has removed both financial and technical barriers to make this a reality. eClinicalWorks customers have also rapidly taken up connections, with nearly triple the number participating today (~2,500) compared to March 2018,” according to the report.

Meditech also made their first connection to CommonWell, and CPSI has made notable progress this year as well, KLAS reports. Cerner continues to actively push for customer participation and has added 35 hospital customers.

“Virence Health (GE Healthcare) has been slower to get out of the gate despite good feedback from early adopters,” the KLAS researchers wrote. “Greenway Health also doesn’t have much momentum, and overall, interviewed Greenway organizations are the least excited about their CommonWell connection.”

KLAS researchers also note that with CommonWell and Carequality linked, the biggest technical obstacle to widespread patient-record sharing has been removed, and the biggest remaining obstacle is local community adoption. “The healthcare industry is rapidly approaching the point where an organization using any of the major acute care/ambulatory EMRs should be able to easily connect to other provider organizations with minimal cost and effort,” KLAS researchers state. “Many vendors have eliminated obstacles on the path to data exchange—all but Virence offer connections to customers at no cost, and all but Cerner have made this plug and play by removing technical barriers.”

“Today, the biggest barriers preventing widespread participation are governance and the need for organizations to decide to participate. Even Epic and athenahealth customers report diminished value from their connection when local exchange partners opt not to connect to the national networks,” KLAS researchers wrote in the report. KLAs also believes that until other vendors take an opt-out approach, provider organization leaders will need to be proactive in promoting local connections to the networks to ensure high value from the connection.

See more on Interoperability

agario agario---betebet sohbet hattı betebet bahis siteleringsbahis