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 HIPAA for FREE!!

Study Offers Snapshot Of Provider App Preferences

Posted on March 20, 2017 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

A recent study backed by HIT industry researchers and an ONC-backed health tech project offers an interesting window into how healthcare organizations see freestanding health apps. The research, by KLAS and the SMART Health IT Project, suggests that providers are developing an increasingly clear of what apps they’d like to see and how they’d use them.

Readers of this blog won’t be surprised to hear that it’s still early in the game for healthcare app use. In fact, the study notes, about half of healthcare organizations don’t formally use apps at the point of care. Also, most existing apps offer basic EMR data access, rather than advanced use cases.

The apps offering EMR data access are typically provided by vendors, and only allow users to view such data (as opposed to documenting care), according to the study report. But providers want to roll out apps which allow inputting of clinical data, as this function would streamline clinicians’ ability to make an initial patient assessment, the report notes.

But there are other important app categories which have gained an audience, including diagnostic apps used to support patient assessment, medical reference apps and patient engagement apps.  Other popular app types include clinical decision support tools, documentation tools and secure messaging apps, according to researchers.

It’s worth noting, though, that there seems to be a gap between what providers are willing to use and what they are willing to buy or develop on their own. For example, the report notes that nearly all respondents would be willing to buy or build a patient engagement app, as well as clinical decision support tools and documentation apps. The patient engagement apps researchers had in would manage chronic conditions like diabetes or heart disease, both very important population health challenges.

Hospital leaders, meanwhile, expressed interest in using sophisticated patient portal apps which go beyond simply allowing patients to view their data. “What I would like a patient app to do for us is to keep patients informed all throughout their two- to four-hours ED stay,” one CMO told researchers. “For instance, the app could inform them that their CBC has come back okay and that their physician is waiting on the read. That way patients would stay updated.”

When it came to selecting apps, respondents placed a top priority on usability, followed by the app’s cost, clinical impact, capacity for integration, functionality, app credibility, peer recommendations and security. (This is interesting, given many providers seem to give usability short shrift when evaluating other health IT platforms, most notably EMRs.)

To determine whether an app will work, respondents placed the most faith in conducting a pilot or other trial. Other popular approaches included vendor demos and peer recommendations. Few favored vendor websites or videos as a means of learning about apps, and even fewer placed working with app endorsement organizations or discovering them at conferences.

But providers still have a few persistent worries about third-party apps, including privacy and security, app credibility, the level of ongoing maintenance needed, the extent of integration and data aggregation required to support apps and issues regarding data ownership. Given that worrisome privacy and security concerns are probably justified, it seems likely that they’ll be a significant drag on app adoption going forward.

E-Patient Update: Patients Need Better Care Management Workflows

Posted on March 10, 2017 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Now and then, I get a little discouraged by the state of my health data. Like providers, I’m frustrated as heck by the number of independent data sources I must access to get a full picture of my medications, care and health status. These include:

* The medication tracker on my retail pharmacy’s site
* My primary care group’s portal
* My hospital’s Epic MyChart portal
* A medication management app to track my compliance with my regimen
* A health tracker app in which I track my blood pressure
* My Google calendar, to keep up with my health appointments
* Email clients to exchange messages with some providers

That’s not all – I’m sure I could think of other tools, interfaces and apps – but it offers a good idea of what I face. And I’m pretty sure I’m not unusual in this regard, so we’re talking about a big issue here.

By the way, bear in mind I’m not just talking about hyperportalotus – a fun term for the state of having too many portals to manage – but rather, a larger problem of data coordination. Even if all of my providers came together and worked through a shared single portal, I’d still have to juggle many tools for tracking and documenting my care.

The bottom line is that given the obstacles I face, my self-care process is very inefficient. And while we spend a lot of time talking about clinician workflow (which, of course, is quite important) we seldom talk about patient/consumer health workflow. But it’s time that we did.

Building a patient workflow

A good initial step in addressing this problem might be to create a patient self-care workflow builder and make it accessible website. Using such a tool, I could list all of the steps I need to take to manage my conditions, and the tool would help me develop a process for doing so effectively.

For example, I could “tell” the software that I need to check the status of my prescriptions once a week, visit certain doctors once a month, check in about future clinical visits on specific days and enter my data in my medication management app twice a day. As I did this, I would enter links to related sites, which would display in turn as needed.

This tool could also display critical web data, such as the site compiling the blood sugar readings from my husband’s connected blood glucose monitor, giving patients like me the ability to review trends at a glance.

I haven’t invented the wheel here, of course. We’re just talking about an alternate approach to a patient portal. Still, even this relatively crude approach – displaying various web-based sources under one “roof” along with an integrated process – could be quite helpful.

Eventually, health IT wizards could build much more sophisticated tools, complete with APIs to major data sources, which would integrate pretty much everything patients need first-hand. This next-gen data wrangler would be able to create charts and graphs and even issue recommendations if the engine behind it was sophisticated enough.

Just get started

All that being said, I may be overstating how easy it would be to make such a solution work. In particular, I’m aware that integrating a tool with such disparate data sources is far, far easier said than done. But why not get started?

After all, it’s hard to overestimate how much such an approach would help patients, at least those who are comfortable working with digital health solutions. Having a coordinated, integrated tool in place to help me manage my care needs would certainly save me a great deal of time, and probably improve my health as well.

I urge providers to consider this approach, which seems like a crying need to me. The truth is, most of the development money is going towards enabling the professionals to coordinate and manage care. And while that’s not a bad thing, don’t forget us!

The Case For Accidental Interoperability

Posted on December 22, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Many of us who follow #HITsm on Twitter have encountered the estimable standards guru Keith Boone (known there as @motorcycle_guy). Keith always has something interesting to share, and his recent article, on “accidental” interoperability, is no exception.

In his article, he describes an aha moment: “I had a recent experience where I saw a feature one team was demonstrating in which I could actually integrate one of my interop components to supply additional functionality,” he writes. “When you build interop components right, this kind of accidental interop shows up all the time.”

In his piece, he goes on to argue that this should happen a lot more often, because by doing so, “you can create lot of value through it with very little engineering investment.”

In an ideal world, such unplanned instances of interoperability would happen often, allowing developers and engineers to connect solutions with far less trouble and effort. And the more often that happened, the more resources everyone involved would have to invest in solving other types of problems.

But in his experience, it can be tough to get dev teams into the “component-based” mindset that would allow for accidental interoperability. “All too often I’ve been told those more generalized solutions are ‘scope expansions,’ because they don’t fit the use case,” and any talk of future concerns is dropped, he says.

While focusing on a particular use case can save time, as it allows developers to take shortcuts which optimize their work for that use case, this approach also limits the value of their work, he argues. Unfortunately, this intense focus prevents developers from creating more general solutions that might have broader use.

Instead of focusing solely on their short-term goals, he suggests, health IT leaders may want to look at the bigger picture. “My own experience tells me that the value I get out of more general solutions is well worth the additional engineering attention,” he writes. “It may not help THIS use case, but when I can supply the same solution to the next use case that comes along, then I’ve got a clear win.”

Keith’s article points up an obstacle to interoperability that we don’t think much about right now. While most of what I read about interoperability options — including on this blog — focus on creating inter-arching standards that can tie all providers together, we seldom discussed the smaller, day-to-day decisions that stand in the way of health data sharing.

If he’s right (and I have little doubt that he is) health IT interoperability will become a lot more feasible, a lot more quickly, if health organizations take a look at the bigger purposes an individual development project can meet. Otherwise, the next project may just be another silo in the making.

ONC Announces Winners Of FHIR App Challenge

Posted on August 3, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

The ONC has announced the first wave of winners of two app challenges, both of which called for competitors to use FHIR standards and open APIs.

As I’ve noted previously, I’m skeptical that market forces can solve our industry’s broad interoperability problems, even if they’re supported and channeled by a neutral intermediary like ONC. But there’s little doubt that FHIR has the potential to provide some of the benefits of interoperability, as we’ll see below.

Winners of Phase 1 of the agency’s Consumer Health Data Aggregator Challenge, each of whom will receive a $15,000 award, included the following:

  • Green Circle Health’s platform is designed to provide a comprehensive family health dashboard covering the Common Clinical Data Set, using FHIR to transfer patient information. This app will also integrate patient-generated health data from connected devices such as wearables and sensors.
  • The Prevvy Family Health Assistant by HealthCentrix offers tools for managing a family’s health and wellness, as well as targeted data exchange. Prevvy uses both FHIR and Direct messaging with EMRs certified for Meaningful Use Stage 2.
  • Medyear’s mobile app uses FHIR to merge patient records from multiple sources, making them accessible through a single interface. It displays real-time EMR updates via a social media-style feed, as well as functions intended to make it simple to message or call clinicians.
  • The Locket app by MetroStar Systems pulls patient data from different EMRs together onto a single mobile device. Other Locket capabilities include paper-free check in and appointment scheduling and reminders.

ONC also announced winners of the Provider User Experience Challenge, each of whom will also get a $15,000 award. This part of the contest was dedicated to promoting the use of FHIR as well, but participants were asked to show how they could enhance providers’ EMR experience, specifically by making clinical workflows more intuitive, specific to clinical specialty and actionable, by making data accessible to apps through APIs. Winners include the following:

  • The Herald platform by Herald Health uses FHIR to highlight patient information most needed by clinicians. By integrating FHIT, Herald will offer alerts based on real-time EMR data.
  • PHRASE (Population Health Risk Assessment Support Engine) Health is creating a clinical decision support platform designed to better manage emerging illnesses, integrating more external data sources into the process of identifying at-risk patients and enabling the two-way exchange of information between providers and public health entities.
  • A partnership between the University of Utah Health Care, Intermountain Healthcare and Duke Health System is providing clinical decision support for timely diagnosis and management of newborn bilirubin according to evidence-based practice. The partners will integrate the app across each member’s EMR.
  • WellSheet has created a web application using machine learning and natural language processing to prioritize important information during a patient visit. Its algorithm simplifies workflows incorporating multiple data sources, including those enabled by FHIR. It then presents information in a single screen.

As I see it, the two contests don’t necessarily need to be run on separate tracks. After all, providers need aggregate data and consumers need prioritized, easy-to-navigate platforms. But either way, this effort seems to have been productive. I’m eager to see the winners of the next phase.

FHIR Product Director Speaks Out On FHIR Hype

Posted on June 6, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

To date, all signs suggest that the FHIR standard set has tremendous promise, and that FHIR adoption is growing by leaps and bounds. In fact, one well-connected developer I spoke with recently argues that FHIR will be integrated into ONC’s EHR certification standards by 2017, when MACRA demands its much ballyhooed “widespread interoperability.”

However, like any other new technology or standard, FHIR is susceptible to being over-hyped. And when the one suggesting that FHIR fandom is getting out of control is Grahame Grieve, FHIR product director, his arguments definitely deserve a listen.

In a recent blog post, Grieve notes that the Gartner hype cycle predicts that a new technology will keep generating enthusiasm until it hits the peak of inflated expectations. Only after falling into te trough of disillusionment and climbing the slope of enlightenment does it reach the plateau of productivity, the Gartner model suggests.

Now, a guy who’s driving FHIR’s development could be forgiven for sucking up the praise and excitement around the emerging standard and enjoying the moment. Instead, though, it seems that Grieve thinks people are getting ahead of themselves.

To his way of thinking, the rate of hype speech around FHIR continues to expand. As he sees it, people are “[making] wildly inflated claims about what is possible, (wilfully) misunderstanding the limitations of the technology, and evangelizing the technology for all sorts of ill judged applications.”

As Grieve sees it, the biggest cloud of smoke around FHIR is that it will “solve interoperability.” And, he flatly states, it’s not going to do that, and can’t:

FHIR is two things: a technology, and a culture. I’m proud of both of those things…But people who think that [interoperability] will be solved anytime soon don’t understand the constraints we work under…We have severely limited ability to standardise the practice of healthcare or medicine. We just have to accept them as they are. So we can’t provide prescriptive information models. We can’t force vendors or institutions to do things the same way. We can’t force them to share particular kinds of information at particular times. All we can do is describe a common way to do it, if people want to do it.

The reality is that while FHIR works as a means of sharing information out of an EHR, it can’t force different stakeholders (such as departments, vendors or governments) to cooperate successfully on sharing data, he notes. So while the FHIR culture can help get things done, the FHIR standard — like other standards efforts — is just a tool.

To be sure, FHIR seems to have legs, and efforts like the Argonaut Project — which is working to develop a first-generation FHIR-based API and Core Data Services specification — are likely to keep moving full steam ahead.

But as Grieve sees it, it’s important to keep the pace of FHIR work deliberate and keep fundamentals like solid processes and well-tested specifications in mind: “If we can get that right — and it’s a work in process — then the trough of despair won’t be as deep as it might.”

The Downside of Interoperability

Posted on May 2, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

It’s hard to argue that achieving health data interoperability is not important — but it comes with risks. And I’ve seen little discussion of the fact that interoperability may actually increase the chance that a major attack could hit a wide swath of healthcare providers. It might be extreme to suggest that we put off such efforts until we step up the industry’s security status, but the problem shouldn’t be ignored either.

Sure, data interoperability is a critical goal for healthcare providers of all stripes. While there’s room to argue about how it should be accomplished, particularly over whether providers or patients should drive health data management, there’s no question it needs to get done. There’s little doubt that most efforts to coordinate care will fall flat if providers are operating with incomplete information.

And what’s more, with the demand for interoperability baked into MACRA, we pretty much have no choice but to make it happen anyway. To my knowledge, HHS has proposed neither carrot nor stick to convince providers to come on board – nor has it defined “widespread” interoperability to my knowledge — but the agency has to achieve something by 2018, and that means change will come.

That being said, I’m struck by how little industry concern there seems to be about the extent to which interoperability can multiply the possibility of a breach occurring. Unfortunately, security is only as good is the weakest link in the chain, and data sharing increases the length of the chain exponentially. Of course, the risk varies a great deal depending on who or what the data-sharing intermediary is, but the fact remains that a connected network is a connected network.

The problem only gets worse if interoperability is achieved by integrating applications. I’m no software engineer, but I’m pretty sure that the more integrated providers’ infrastructure is, the more vulnerabilities they share. To be fair, hospitals theoretically vet their partners, but that defeats the purpose of universal data sharing, doesn’t it?

And even if every provider in the universal data sharing network practices good security hygiene, they can still get attacked. So it’s not a matter of requiring participants to comply with some network security standard, or meet some certification criteria. Given the massive incentives these have to steal health data (and lock it up with ransomware), nobody can hold out forever.

The bottom line is that I believe we should discuss the matter of security in a fully-connected health data sharing network more often.

Yes, we almost certainly need to press ahead and simply find a way to contain the risks. We simply can’t afford our fragmented healthcare system, and data interoperability offers perhaps the best possible chance of pulling it back together.

But before we plunge into the fray, it only makes sense to stop and consider all of the risks involved and how they should be addressed. After all, universal interconnection exposes a virtually infinite number of potential points of failure to cybercrooks. Let’s put some solutions on the table before it’s too late.

This Time, It’s Personal: Virus Hits My Local Hospital

Posted on March 30, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

In about two weeks, I am scheduled to have a cardiac ablation to address a long-standing arrhythmia. I was feeling pretty good about this — after all, the procedure is safe at my age and is known to have a very high success rate — until I scanned my Twitter feed yesterday.

It was then that I found out that what was probably a ransomware virus had forced a medical data shutdown at Washington, D.C.-based MedStar Health. And while the community hospital where my procedure will be done is not part of the MedStar network, the cardiac electrophysiologist who will perform the ablation is affiliated with the chain.

During my pre-procedure visit with the doctor, a very pleasant guy who made me feel very safe, we devolved to talking shop about EMR issues after the clinical discussion was over. At the time he shared that his practice ran on GE Centricity which, he understandably complained, was not interoperable with the Epic system at one community chain, MedStar’s enterprise system or even the imaging platforms he uses. Under those circumstances, it’s hard to imagine that my data was affected by this breach. But as you can imagine, I still wonder what’s up.

While there’s been no official public statement saying this virus was part of a ransomware attack, some form of virus has definitely wreaked havoc at MedStar, according to a report by the Washington Post. (As a side note, it’s worth pointing out that if this is a ransomware attack, health system officials have done an admirable job of keeping the amount demanded for data return out of the press. However, some users have commented about ransomware on their individual computers.)

As the news report notes, MedStar has soldiered on in the face of the attack, keeping all of its clinical facilities open. However, a hospital spokesperson told the newspaper that the chain has decided to take down all system interfaces to prevent the spread of the virus. And as has happened with other hospital ransomware incursions, staffers have had to revert to using paper-based records.

And here’s where it might affect me personally. Even though my procedure is being done at a non-MedStar hospital, it’s possible that the virus driven delay in appointments and surgeries will affect my doctor, which could of course affect me.

Meanwhile, imagine how the employees at MedStar facilities feel: “Even the lowest-level staff can’t communicate with anyone. You can’t schedule patients, you can’t access records, you can’t do anything,” an anonymous staffer told the Post. Even if such a breach had little impact on patients, it’s obviously bad for employee morale. And that can’t be good for me either.

Again, it’s possible I’m in the clear, but the fact that the FUD surrounding this episode affects even a trained observer like myself plays right into the virus makers’ hands. Now, so far I haven’t dignified the attack by calling the doctor’s office to ask how it will affect me, but if I keep reading about problems with MedStar systems I’ll have to follow up soon.

Worse, when I’m being anesthetized for the procedure next month, I know I’ll be wondering when the next virus will hit.

Mobile Health Security Issues To Ponder In 2016

Posted on January 11, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

In some ways, mobile health security safeguards haven’t changed much for quite some time. Making sure that tablets and phones are protected against becoming easy network intrusion points is a given. Also seeing to it that such devices use strong passwords and encrypted data exchange whenever possible is a must.

But increasingly, as mobile apps become more tightly knit with enterprise infrastructure, there’s more security issues to consider. After all, we’re increasingly talking about mission-critical apps which rely on ongoing access to sensitive enterprise networks. Now more than ever, enterprises must come up with strategies which control how data flows into the enterprise network. In other words, we’re not just talking about locking down the end points, but also seeing to it that powerful edge devices are treated like the vulnerable hackable gateways they are.

To date, however, there’s still not a lot of well-accepted guidance out there spelling out what steps health organizations should take to ramp up their mobile security. For example, NIST has issued its “Securing Electronic Health Records On Mobile Devices” guideline, but it’s only a few months old and remains in draft form to date.

The truth is, the healthcare industry isn’t as aware of, or prepared for, the need for mobile healthcare data security as it should be. While healthcare organizations are gradually deploying, testing and rolling out new mobile platforms, securing them isn’t being given enough attention. What’s more, clinicians aren’t being given enough training to protect their mobile devices from hacks, which leaves some extremely valuable data open to the world.

Nonetheless, there are a few core approaches which can be torqued up help protect mobile health data this year:

  • Encryption: Encrypting data in transit wasn’t invented yesterday, but it’s still worth a check in to make sure your organization is doing so. Gregory Cave notes that data should be encrypted when communicated between the (mobile) application and the server. And he recommends that Web traffic be transmitted through a secure connection using only strong security protocols like Secure Sockets Layer or Transport Layer Security. This also should include encrypting data at rest.
  • Application hardening:  Before your organization rolls out mobile applications, it’s best to see to it that security defects are detected before and addressed before deployment. Application hardening tools — which protect code from hackers — can help protect mobile deployments, an especially important step for software placed on machines and locations your organization doesn’t control. They employ techniques such as obfuscation, which hides code structure and flow within an application, making it hard for intruders to reverse engineer or tamper with the source code.
  • Training staff: Regardless of how sophisticated your security systems are, they’re not going to do much good if your staff leaves the proverbial barn door open. As one security expert points out,  healthcare organizations need to make staffers responsible for understanding what activities lead to breaches, or security hackers will still find a toehold.”It’s like installing the most sophisticated security system in the world for your house, but not teaching the family how to use it,” said Grant Elliott, founder and CEO of risk management and compliance firm Ostendio.

In addition to these efforts, I’d argue that staffers need to really get it as to what happens when security goes awry. Knowing that mistakes will upset some IT guy they’ve never met is one thing; understanding that a breach could cost millions and expose the whole organization to disrepute is a bit more memorable. Don’t just teach the security protocols, teach the costs of violating them. A little drama — such as the little old lady who lost her home due to PHI theft — speaks far more powerfully than facts and figures, don’t you agree?

Analytics Integration Back to EHR Can’t Disrupt the Workflow

Posted on November 3, 2015 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

One of the challenges we face with healthcare analytics is getting the right information to the right care provider at the right time. In many cases that means presenting the analytics information to the doctor or nurse in the EHR at the point of care. It’s hard enough to know which data to present to which person and at what point in the care process. However, EHR vendors have made this integration even more difficult since it’s not easy to interface the healthcare analytics insights into the EHR workflow. The integrations that I’ve seen are crude at best.

That’s absolutely where we need to go though. There are very few situations where you can disrupt the healthcare providers workflow and send them to another system. I love the second screen concept as much as the next, but that’s not reasonable for most organizations.

I did recently talk to a BI Manager from a hospital who talked about the way they’ve integrated some of their analytics into the EHR workflow of their doctors. What they were doing was basic at best, but did illustrate an important point of learning: inform, don’t interrupt.

The concept of informing the doctor and not interrupting the doctor is a good one. While there are likely a few cases where you’d want to interrupt the doctor, it’s more common that you want to inform the doctor of some insight on the patient as opposed to interrupting the workflow. Doctors love having the right information at their fingertips. Interrupting their workflow (especially when it was unnecessary) causes alert fatigue.

No doubt you have to be careful with how you inform the doctor as well. The insights you offer the doctor better be actionable and useful or they’ll become blind to that as well. That’s the challenge we face with healthcare analytics. How do we take the data and make it useful to the providers? The first step is going to be creating a pathway of communication from the analytics into the EHR. Everything else will evolve from that connection.

My Prediction for the Epic App Store

Posted on March 5, 2015 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Today I was talking with a healthcare IT vendor which really needs to integrate deeply with an EHR to be valuable. Without that integration the product is not nearly as useful for doctors. Therefore we started talking about their current EHR integration and the potential for future EHR integrations. At that point he asked me what I thought about the coming Epic App Store (officially called the Epic App Exchange).

In case you missed it, I wrote about the Epic App Store over on Hospital EMR and EHR. I cover what’s been said about the Epic App Store (not much from Epic itself) and make some predictions. However, today’s conversation solidified my predictions.

Epic has always been open to working with their customers and a tech partner to integrate something with Epic. Basically, the customer is king and so if the customer wants the integration, Epic will provide the SDK that’s needed for the integration and make it possible for the customer to do what they need. Everyone’s known that if you want to integrate with Epic, then you need to work through a customer.

With this in mind, I believe the Epic app store is a way for Epic to allow for distribution of these apps that have been created by their customers (often with a tech partner) to other Epic customers.

Basically, this is in line with Judy’s focus on the customer. Some might say that this focus is great. Hard to argue with Epic’s success. However, this approach misses out on the opportunity of the Epic app store facilitating entrepreneurial innovators to build something on top of Epic that their customers didn’t even know they wanted yet.

Epics current strategy is more in line with staying the entrenched incumbent. Real transformation comes when you provide a platform for innovation that goes beyond yourself and your customers. I hope one day Epic sees this vision and really roles out an open app store. Until then, the Epic connected customer applications are going to have a bit of a monopoly selling their add on services to Epic customers.