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, it looks like Epic has begun to try and demonstrate that it’s not selling a walled garden. Honestly, I doubt it will manage to convince me, but I’m trying to keep an open mind on the matter. I do have to admit that it’s made some steps forward.

One example of this trend is the launch of App Orchard, a program allowing medical practices and hospitals to build customized apps on its platform. App Orchard also supports independent mobile app developers that target providers and patients.

Marking a break from Epic’s past practices, the new program lets developers use a FHIR-based API to access and Epic development sandbox. (Previously, Epic wouldn’t give mobile app developers permission to connect to its EMR unless a customer requested permission on its behalf.) We’ll have to keep an eye on the contracts they require developers to sign to see if they’re really opening up Epic or not.

But enough about App Orchard. The latest news from Epic is its launch of Share Everywhere, a new tool which will give patients the ability to grant access to their health data to any provider with Internet access. The provider in question doesn’t even have to have an EHR in place. Share Everywhere will be distributed to Epic customers at no cost in the November update of its MyChart portal.

Share Everywhere builds on its Care Everywhere tool, which gives providers the ability to share data with other healthcare organizations. Epic, which launched Care Everywhere ten years ago, says 100% of its health system customers can exchange health data using the C-CDA format.

To use Share Everywhere, patients must log into MyChart and generate a one-time access code. Patients then give the code to any provider with whom they wish to share information, according to a report in Medscape. Once they receive the code, the clinician visits the Share Everywhere website, then uses the code once they verify it against the patient’s date of birth.

As usual, the biggest flaw in all this is that Epic’s still at the center of everything. While patients whose providers use Epic gain options, patients whose health information resides in a non-Epic system gain nothing.

Also, while it’s good that Epic is empowering patients, Direct record sharing seems to offer more. After all, patients using Direct don’t have to use a portal, need not have any particular vendor in the mix, and can attach a wide range of file formats to Direct messages, including PDFs, Word documents and C-CDA files. (This may be why CHIME has partnered with DirectTrust to launch its broad-based HIE.)

Participating does require a modest amount of work — patients have to get a Direct Address from one of its partners — and their provider has to be connected to the DirectTrust network. But given the size of its network, Direct record sharing compares favorably with Share Everywhere, without involving a specific vendor.

Despite my skepticism, I did find Share Everywhere’s patient consent mechanism interesting. Without a doubt, seeing to it that patients have consented to a specific use or transmission of their health data is a valuable service. Someday, blockchain may make this approach obsolete, but for now, it’s something.

Nonetheless, overall I see Share Everywhere as evolutionary, not revolutionary. If this is the best Epic can do when it comes to patient data exchange, I’m not too impressed.

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.

I can’t believe I missed this. Apparently, financial giant USAA announced earlier this year that it’s collecting health data from life insurance applicants by interfacing with patient portals. While it may not be the first life insurer to do so, I haven’t been able to find any others, which makes this pretty interesting.

Usually, when someone applies for life insurance, they have to produce medical records which support their application. (We wouldn’t want someone to buy a policy and pop off the next day, would we?) In the past, applicants have had to push their providers to send medical records to the insurer. As anyone who’s tried to get health records for themselves knows, getting this done can be challenging and is likely to slow down policy approvals.

Thanks to USAA’s new technology implementation, however, the process is much simpler. The new offering, which is available to applicants at the Department of Veterans Affairs and Department of Defense, allows consumers to deliver their health data directly to the insurer via their patient portal.

To make this possible, USAA worked with Cerner on EHR retrieval technology. The technology, known as HealtheHistory, supports health data collection, encrypts data transmission and limits access to EHR data to approved persons. No word yet as to whether Cerner has struck similar deals elsewhere but it wouldn’t surprise me.

USAA’s new EHR-based approach has paid off nicely. The life insurer has seen an average 30-day reduction in the time it takes to acquire health records for applicants, and though it doesn’t say what the average was back in the days of paper records, I assume that this is a big improvement.

And now on to the less attractive aspects of this deal. I don’t know about you, but I see a couple of red flags here.

First, while life insurers may know how to capture health data, I doubt they’re cognizant of HIPAA nuances. Even if they hire a truckload of HIPAA experts, they don’t have much context for maintaining HIPAA compliance. What’s more, they rarely if ever have to look a patient in the face, which serves as something of a natural deterrent to provider data carelessness.

Also, given the industry’s track record, is it really a good idea to give a life insurer that much data? For example, consider the case of a healthy 36-year-old woman with no current medical issues who was denied coverage because she had the BRCA 1 gene. That gene, as some readers may know, is associated with an increased risk of breast and ovarian cancer.

The life insurer apparently found out about the woman’s makeup as part of the application process, which included queries about genetic information. Apparently, the woman had had such testing, and as a result had to disclose it or risk being accused of fraud.

While the insurer in question may have the right, legally, to make such decisions, their doing so falls into a gray area ethically. What’s more, things would get foggier if, say, it decided to share such information with a sister health insurance division. Doing so may not be legal but I can easily see it happening.

Should someone’s genes be used to exclude them life or health insurance? Bar them from being approved for a mortgage from another sister company? Can insurers be trusted to meet HIPAA standards for use of PHI? It’ll be important to address such questions before we throw our weight behind open health data sharing with companies like USAA.

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.

In 1988, some members of the cable television industry got together to form CableLabs, a non-proft innovation center and R&D lab. Since then, the non-profit has been a driving force in bringing cable operators together, developing technologies and specifications for services as well as offering testing and certification facilities.

Among its accomplishments is the development of DOCSIS (Data-over-Cable Service Interface Specification), a standard used worldwide to provide Internet access via a cable modem. If your cable modem is DOCSIS compliant, it can be used on any modern cable network.

If you’re thinking this approach might work well in healthcare, you’re not the only one. In fact, a group of powerful healthcare providers as just launched a health data sharing-focused organization with a similar approach.

The Center for Medical Interoperability, which will be housed in a 16,000-square-foot location in Nashville, is a membership-based organization offering a testing and certification lab for devices and systems. The organization has been in the works since 2011, when the Gary and Mary West Health Institute began looking at standards-based approaches to medical device interoperability.

The Center brings together a group of top US healthcare systems – including HCA Healthcare, Vanderbilt University and Community Health Systems — to tackle interoperability issues collaboratively. Taken together, the board of directors represent more than 50 percent of the healthcare industry’s purchasing power, said Kerry McDermott, vice president of public policy and communications for the Center.

According to Health Data Management, the group will initially focus on acute care setting within a hospital, such as the ICU. In the ICU, patients are “surrounded by dozens of medical devices – each of which knows something valuable about the patient — but we don’t have a streamlined way to aggregate all that data and make it useful for clinicians,” said McDermott, who spoke with HDM.

Broadly speaking, the Center’s goal is to let providers share health information as seamlessly as ATMs pass banking data across their network. To achieve that goal, its leaders hope to serve as a force for collaboration and consensus between healthcare organizations.

The project’s initial $10M in funding, which came from the Gary and Mary West Foundation, will be used to develop, test and certify devices and software. The goal will be to develop vendor-neutral approaches that support health data sharing between and within health systems. Other goals include supporting real-time one-to-many communications, plug-and-play device and system integration and the use of standards, HDM reports.

It will also host a lab known as the Transformation Learning Center, which will help clinicians explore the impact of emerging technologies. Clinicians will develop use cases for new technologies there, as well as capturing clinical requirements for their projects. They’ll also participate in evaluating new technologies on their safety, usefulness, and ability to satisfy patients and care teams.

As part of its efforts, the Center is taking a close look at the FHIR API. Still, while FHIR has great potential, it’s not mature yet, McDermott told the magazine.

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.

Despite the ever-mounting levels of physician frustration, in some ways EMRs have changed little from their mass-market rollout. EMR interfaces are still counterintuitive, data sharing possibilities are limited, important information still lives in isolated silos and endless data entry is the rule rather than exception.

In theory, we could do better if we had a reasonable vision of what should come next. For example, I was intrigued by ideas proposed by Dr. Robert Rowley of Flow Health. He describes a model in which EMRs draw on a single, external data source which isn’t confined to any one organization. Providers would access, download and add data through a modern API. Given such fluid access to data, providers would be able to create custom front-ends based on a collection of apps, rather than rely on a single vendor-created interface.

Unfortunately, EMR vendors are unlikely to take on a completely different approach like Rowley’s, for reasons inherent to their business model. After all, they have little reason to develop new, innovative EMRs which rely on a different data architecture. Not only that, the costs associated with developing and rolling out a completely new EMR model would probably be very high. And what company would take that chance when their existing “big iron” approach still sells?

Not only that, EMR vendors would risk alienating their customers if they stray too far off the ranch. While an innovative new platform might be attractive to some buyers, it might also be incompatible with their existing technology. And it would probably require both providers and vendors to reinvent workflows and transform their technical architecture.

Meanwhile, in addition to finding a way to pay for the technology, providers would have to figure out how to integrate their existing data into the new system, integrate the platform with its existing infrastructure, retrain the staff and clinicians and cope with reduced productivity for at least a year or two. And what would become of their big data analytics code? Their decision support modules? Even data entry could be a completely new game.

Smaller medical practices could be pushed into bankruptcy if they have to invest in yet another system. Large practices, hospitals and health systems might be able to afford the initial investment and systems integration, but the project would be long and painful. Unless they were extremely confident that it would pay off, they probably wouldn’t risk giving a revolutionary solution a try.

All that being said, there are forces in play which might push vendors to innovate more, and give providers a very strong incentive to try a new approach to patient data management. In particular, the need to improve care coordination and increase patient engagement – driven by the emergence of value-based care – is putting providers under intense pressure. If a new platform could measurably improve their odds of surviving this transition, they might be forced to adopt it.

Right now, providers who can afford to do so are buying freestanding care coordination and patient engagement tools, then integrating them into their existing EMRs. I can certainly see the benefit of doing so, as it brings important functions on board without throwing out the baby with the bathwater. And these organizations aren’t forced to rethink their fundamental technical strategy.

But the truth is, this model is unlikely to serve their needs over the long term. Because it relies on existing technology, welding new functions onto old, clinicians are still forced to grappled with kludgy technology. What’s more, these solutions add another layer to a very shaky pile of cards. And it’s hard to imagine that they’re going to support data interoperability, either.

Ultimately, the healthcare industry is going to be bogged down with short-term concerns until providers and vendors come together and develop a completely new approach to health data. To succeed at changing their health IT platform, they’ll have to rethink the very definition of key issues like ease of use and free data access, care coordination, patient engagement and improved documentation.

I believe that’s going to happen, at some point, perhaps when doctors storm the executive offices of their organization with torches and pitchforks. But I truly hope providers and vendors introduce more effective data management tools than today’s EMRs without getting to that point.

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.

It looks like Epic is getting on the FHIR train. According to an article in Modern Healthcare, Epic is launching a new program – serving physician practices and hospitals – to help them build customized apps. The program, App Orchard, will also support independent mobile app developers who target providers and patients.

The launch follows on the heels of a similar move by Cerner, which set up its own sandbox for developers interested in linking to its EMR using FHIR. The Cerner Open Developer Experience (code_), which launched in early 2016, is working with firms creating SMART on FHIR apps.

App Orchard, for its part, lets developers use a FHIR-based API to access an Epic development sandbox. This will allow the developers to address issues in connecting their apps to the Epic EMR. Previously, Epic wouldn’t let mobile app developers connect to its EMR until a customer requested permission on their behalf.

In addition to providing the API, App Orchard will also serve as an online marketplace along the lines of Google Play or the Apple app store. However, end users won’t be able to download the app for their own use — only software developers and vendors will be able to do that. The idea is that these developers will create the apps on contract to customers.

Meanwhile, according to the magazine, Epic will screen and pick an initial group of developers to the program. Brett Gann, who leads the Epic-based team developing App Orchard, told Modern Healthcare that factors which will distinguish one developer from the other include app safety, security, privacy, reliability, system integrity, data integrity and scalability.

As part of their participation, developers will get documentation listing these criteria and what they mean to Epic. The Epic team will expect the developers to commit to following these guidelines and explain how they’ll do so, Gann said.

While Epic hasn’t made any predictions about what types of apps developers will pursue, recent research offers a clue. According to new research by SMART and KLAS, providers are especially interested in apps that help with patient engagement, EMR data viewing, diagnostics, clinical decision support and documentation tasks.

One thing to watch is how Epic decides to handle licensing, ownership, and charges for participation in their Orchard Program. If they have a true open API, then this will be a good move for the industry. If instead they choose to take ownership of everything that’s created, put restrictive licenses on developers, and/or charge huge sums to participate, then it’s unlikely to see much true innovation that’s possible with an open API. We’ll see how that plays out.

Meanwhile, in other Epic news, Becker’s Hospital Reviewnotes that the vendor is planning to develop two additional versions of its EMR. Adam Whitlatch, a lead developer there, told the site that the new versions will include a mid-range EMR with fewer modules (dubbed “utility”), and a slimmer version with fewer modules and advanced features, to be called “Sonnet.”

Whitlatch said the new versions will target physician practices and smaller hospitals, which might prefer a lower-cost EMR that can be implemented more quickly than the standard Epic product. It’s also worth noting that the two new EMR versions will be interoperable with the traditional Epic EMR (known as “all-terrain”).

All told, these are intriguing developments which could have an impact on the EMR industry as a whole.

On the one hand, not only is Epic supporting the movement towards interchangeable apps based on FHIR, it appears that the vendor has decided to give in to the inevitable and started to open up its platform (something it hasn’t done willingly in the past). Over time, this could affect providers’ overall Epic development plans if Epic executes it well and enables innovation on Orchard and doesn’t restrict it.

Also, the new versions of the Epic could make it available to a much wider audience, particularly if the stripped-down versions are significantly cheaper than its signature EMR. In fact, an affordable Epic EMR could trigger a big shakeup in the ambulatory EMR market.

Let’s see if more large EMR vendors decide to offer an open API. If access to EMR APIs became common, it would represent a major shift in the whole health IT ecosystem.

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.

I’ve always enjoyed reading HISTalk, and today was no exception. This time, I came across a piece by a vendor-affiliated physician arguing that it’s time for providers to shift from isolated EMRs to broader, componentized health IT platforms. The piece, by Excelicare chief medical officer Toby Samo, MD, clearly serves his employer’s interests, but I still found the points he made to be worth discussing.

In his column, he notes that broad technical platforms, like those managed by Uber and Airbnb, have played a unique role in the industries they serve. And he contends that healthcare players would benefit from this approach. He envisions a kind of exchange allowing the use of multiple components by varied healthcare organizations, which could bring new relationships and possibilities.

“A platform is not just a technology,” he writes, “but also ‘a new business model that uses technology to connect people, organizations and resources in an interactive ecosystem.’”

He offers a long list of characteristics such a platform might have, including that it:

* Relies on apps and modules which can be reused to support varied projects and workflows
* Allows users to access workflows on smartphones and tablets as well as traditional PCs
* Presents the results of big data analytics processes in an accessible manner
* Includes an engine which allows clients to change workflows easily
* Lets users with proper security authorization to change templates and workflows on the fly
* Helps users identify, prioritize and address tasks
* Offers access to high-end clinical decision support tools, including artificial intelligence
* Provides a clean, easy-to-use interface validated by user experience experts

Now, the idea of shared, component-friendly platforms is not new. One example comes from the Healthcare Services Platform Consortium, which as of last August was working on a services-oriented architecture platform which will support a marketplace for interoperable healthcare applications. The HSPC offering will allow multiple providers to deliver different parts of a solution set rather than each having to develop their own complete solution. This is just one of what seem like scores of similar initiatives.

Excelicare, for its part, offers a cloud-based platform housing a clinical data repository. The company says its platform lets providers construct a patient-specific longitudinal health record on the fly by mining existing EHRs claims repositories and other data. This certainly seems like an interesting idea.

In all candor, my instinct is that these platforms need to be created by a neutral third party – such as travel information network SABRE – rather than connecting providers via a proprietary platform created by companies like Excelicare. Admittedly, I don’t have a deep understanding of Excelicare’s technology works, or how open its platform is, but I doubt it would be viable financially if it didn’t attempt to lock providers into its proprietary technology.

On the other hand, with no one interoperability approach having gained an unbeatable lead, one never knows what’s possible. Kudos to Samo and his colleagues for making an effort to advance the conversation around data sharing and collaboration.

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.

Two formerly competitive health data interoperability groups have agreed to work together to share data with each others’ members. CommonWell Health Alliance, which made waves when it included Cerner but not Epic in its membership, has agreed to share data with Carequality, of which Epic is a part. (Of course, Epic said that it chose not to participate in the former group, but let’s not get off track with inside baseball here!)

Anyway, CommonWell was founded in early 2013 by a group of six health IT vendors (Cerner, McKesson, Allscripts, athenahealth, Greenway Medical Technologies and RelayHealth.) Carequality, for its part, launched in January of this year, with Epic, eClinicalWorks, NextGen Healthcare and Surescripts on board.

Under the terms of the deal, the two will shake hands and play nicely together. The effort will seemingly be assisted by The Sequoia Project, the nonprofit parent under which Carequality operates.

The Sequoia Project brings plenty of experience to the table, as it operates eHealth Exchange, a national health information network. Its members include the AMA, Kaiser Permanente, CVS’s Minute Clinic, Walgreens and Surescripts, while CommonWell is largely vendor-focused.

As things stand, CommonWell runs a health data sharing network allowing for cross-vendor nationwide data exchange. Its services include patient ID management, record location and query/retrieve broker services which enable providers to locate multiple records for patient using a single query.

Carequality, for its part, offers a framework which supports interoperability between health data sharing network and service providers. Its members include payer networks, vendor networks, ACOs, personal health record and consumer services.

Going forward, CommonWell will allow its subscribers to share health information through directed queries with any Carequality participant. Meanwhile, Carequality will create a version of the CommonWell record locator service and make it available to any of its providers.

Once the record-sharing agreement is fully implemented, it should have wide ranging effects. According to The Sequoia Project, CommonWell and Carequality participants cut across more than 90% of the acute EHR market, and nearly 60% of the ambulatory EHR market. Over 15,000 hospitals clinics and other healthcare providers are actively using the Carequality framework or CommonWell network.

But as with any interoperability project, the devil will be in the details. While cross-group cooperation sounds good, my guess is that it will take quite a while for both groups to roll out production versions of their new data sharing technologies.

It’s hard for me to imagine any scenario in which the two won’t engage in some internecine sniping over how to get this done. After all, people have a psychological investment in their chosen interoperability approach – so I’d be astonished if the two teams don’t have, let’s say, heated discussions over how to resolve their technical differences. After all, it’s human factors like these which always seem to slow other worthy efforts.

Still, on the whole I’d say that if it works, this deal is good for health IT. More cooperation is definitely better than less.

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.

As I work to stay on top of my mix of chronic conditions, one thing that stands out to me is that providers expect me to do most of my own medication tracking and management. What I mean by this is that their relationship to my med regimen is fairly static, with important pieces of the puzzle shared between multiple providers. Ultimately, there’s little coordination between prescribers unless I make it happen.

I’ve actually had to warn doctors about interactions between my medications, even when those interactions are fairly well-known and just a Google search away online. And in other cases, specialists have only asked about medications relevant to their treatment plan and gotten impatient when I tried to provide the entire list of prescriptions.

Sure, my primary care provider has collected the complete list of my meds, and even gets a updates when I’ve been prescribed a new drug elsewhere. But given the complexity of my medical needs, I would prefer to talk with her about how all of the various medications are working for me and why I need them, something that rarely if ever fits into our short meeting time.

Regardless of who’s responsible, this is a huge problem. Patients like me are being sent with some general drug information, a pat on the back, and if we experience side effects or are taking meds incorrectly we may not even know it.

So at this point you’re thinking, “Okay, genius, what would YOU do differently?” And that’s a fair question. So here’s what I’d like to see happen when doctors prescribe medications.

First, let’s skip over the issue of what it might take to integrate medication records across all providers’s HIT systems. Instead, let’s create a portal — aggregating all the medication records for all the pharmacies in a given ZIP Code — and allow anyone with a valid provider number and password to log in and review it. The same site could run basic analytics examining interactions between drugs from all providers. (By the way, I’m familiar with Surescripts, which is addressing some of these gaps, but I’m envisioning a non-proprietary shared resource.)

Rather than serving as strictly a database, the site would include a rules engine which runs predictive analyses on what a patient’s next steps should be, given their entire regimen, then generate recommendations specific to that patient. If any of these were particularly important, the recommendations could be pushed to the provider (or if administrative, to staff members) by email or text.

These recommendations, which could range from reminding the patient to refill a critical drug to warning the clinician if an outside prescription interacts with their existing regimen. Smart analytics tools might even be able to predict whether a patient is doing well or poorly by what drugs have been added to their regimen, given the drug family and dosage.

Of course, these functions should ultimately be integrated into the physicians’ EMRs, but at first, hospitals and clinics could start by creating an interface to the portal and linking it to their EMR. Eventually, if this approach worked, one would hope that EMR vendors would start to integrate such capabilities into their platform.

Now I imagine there could be holes in these ideas and I realize how challenging it is to get disparate health systems and providers to work together. But what I do know is that patients like myself get far too little guidance on how to manage meds effectively, when to complain about problems and how to best advocate for ourselves when doctors whip out the prescription pad. And while I don’t think my overworked PCP can solve the problem on her own, I believe it may be possible to improve med management outcomes using smart automation.

Bottom line, I doubt anything will change here unless we create an HIT solution to the problem. After all, given how little time they have already, I don’t see clinicians spending a lot more time on meds. Until then, I’m stuck relying on obsessive research via Dr. Google, brief chats with my frantic retail pharmacist and instincts honed over time. So wish me luck!

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.

Eventually, big EMR vendors will be forced to provide a robust API that makes it easy to attach services on to their core platform. While they may see it as a dilution of their value right now, in time it will become clear that they can’t provide everything to everyone.

For example, is pretty unlikely that companies like Epic and Cerner will build genomics applications, so they’re going to need to connect using an API to add that functionality for their users. (Check out this video with John Lynn, Chris Bradley of Mana Health and Josh Siegel of CareCloud for more background on building a usable healthcare API.)

But as recent research points out, some of the vendors may be dragged kicking and screaming in that direction before they make it easy to connect to their systems. In fact, a new study by Health 2.0 concludes that smaller health IT vendors still face significant difficulties integrating with EMRs created by larger vendors.

The study, which was supported by the California Health Care Foundation, surveyed more than 100 small health technology firms. The researchers found that only two EMR vendors (athenahealth and Allscripts) were viewed by smaller vendors as having a well-advertised, easy to access partner program. When it came to other large vendors, about half were happy with Epic, Cerner and GE’s efforts, while NextGen and eClinicalWorks got low marks for ease of integration, Holt reported.

To get the big vendors on board, it seems as though customer pressure is still critical at present, Holt says. Vendors reported that it helped a great deal if they had a customer who was seeking the integration. The degree to which this mattered varied, but it seemed to be most important in the case of Epic, with 70% of small vendors saying that they needed to have a client recommend them before Epic would get involved in integration project.

But that doesn’t mean it’s smooth sailing from there on out. Even in the case where the big EMR vendors got involved with the integration project, smaller tech vendors weren’t fond of many of their APIs .

More than a quarter of those using Epic and Cerner APIs rated them poorly, followed by 30% for NextGen, GE and MEDITECH and a whopping 50% for eClinicalWorks. The smaller vendors’ favorite APIs seemed to be the ones offered by athenahealth, Allscripts and McKesson. According to Holt, athenahealth’s API got the best ratings overall.

All that being said, some of the smaller vendors weren’t that enthusiastic about pushing for integration with big EMR vendors at present. Of the roughly 30% who haven’t integrated with such vendors, half said it wasn’t worth the effort to try and integrate, for reasons that included the technical or financial cost would be too great. Also, some of the vendors surveyed by Health 2.0 reported they were more focused on other data-gathering efforts, such as accessing wearables data.

Still, EMR vendors large and small need to change their attitude about opening up the platform, and smaller vendors need to support them when they do so. Otherwise, the industry will remain trapped by a self-fulfilling prophecy that true integration can never happen.

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’ve long believed that a rock solid API is going to be required by healthcare IT software companies and EHR vendors in particular. If we want hospitals and doctors to be able to accomplish everything they need to accomplish, we need APIs to connect providers to services that will better serve the patients. EHR vendors aren’t going to do everything. With this in mind, we thought that it was time to start a discussion on how to build a usable healthcare API.

There are a lot of people who talk generally about an API, but very few that have executed it well in healthcare. CareCloud and ManaHealth are two healthcare companies that are trying to implement a health care API in the right way, so we’re excited to sit down with them to talk about their experience building healthcare APIs.