[AutumnCurtain]

The first point he raises is the most critical by far. The silverbacks of the industry deliberately stymie efforts for true interoperability because it goes directly against their primary goal, which is forcing everyone into their platform. Epic in particular has zero intention of allowing anyone else to take their market share by enabling easy sharing of data across platforms. It's far better for them from a business perspective to make interfacing so unreasonably difficult that you are forced to implement their full suite of applications, at which point they hold your organization's data hostage to induce other orgs to do the same. The larger their ecosystem grows, the less they need to worry about interoperability - improving patients' outcomes is not even an afterthought. Their vision of population health reporting is one in which every major healthcare org has been trapped inside their walled garden.

[z3ugma]

Some free advice from an ex-Epic: This is true when it's other vendors doing the data fetching. When it's a health system customer of Epic, they bend over backwards to help them extract the data properly and build cool clinical tools on top of the Epic platform. Health systems with big innovation arms like Atrium and Providence could be a good place to seek VC if your product idea relies on deep EMR access. Sometimes the left hand doesn't talk to the right in these health systems though - you'll need to get that innovation arm talking to the EMR analysts. Use the shibboleth "I want to talk to our Epic TS" for whatever speciality you work on.

As for things like the App Orchard and Epic on FHIR https://fhir.epic.com/ : Epic is smart enough to realize that their future lies as the platform of the health system IT stack, in the Ben Thompson sense of a platform / aggregator.

The hospitals are scared of open access, and Epic always does what's in the best interest of their customers, so they push against open access.

[bearjaws]

Epic on FHIR is missing a ton of data that is present in Epic, for example if I want to react to a dispensing event, that has to be custom built as far as I know. Even then, you're long polling an endpoint hoping you find work you need to react to.

At times it feels like it would be better to just get data straight from the database, as custom Epic implementation times are insanely long and costly.

[nradov]

I don't know about dispensing events specifically, but Epic supports CDS Hooks to allow for triggering custom code in response to certain events.

Getting data straight from an EHR's underlying database is risky. The vendors generally don't document or support this, and the schema could change at any time.

[nimish]

Well, you don't end up having to query their DB directly, you can do it via standardized IHE ITI XDS/XCA over a network like CareQuality. There are startups like Particle that can do it as a SaaS.

[bearjaws]

Have you used Particle? I find the concept really interesting and could help me in the future. Would love a end user opinion.

[nimish]

Full disclosure, I was an early employee and wrote the first integrations, so I'm likely not the right person to ask. https://www.particlehealth.com/ should have details.

[abrichr]

Thanks for sharing. Can you please suggest some resources for further reading? Is particle.io the startup you mentioned?

[nimish]

https://www.particlehealth.com/ -- full disclosure, I was an early employee

[nimish]

Ehh, Epic cares about Epic. They lose their gatekeeping ability once TEFCA roles out with teeth.

The P in HIPAA stands for portability, of course.

[bduerst]

Yeah, ex-Epic here as well. Epic's data surfaces are byzantine almost by design, as a form of security or safety. It can only be construed as gatekeeping in that Epic has never prioritized making it better for non-customers.

[colinmhayes]

Epic controls 55% of the EMR market, and that number is only growing. It won't be long until this isn't a problem because the majority of the population has all their records with Epic.

[paulmd]

Yes, EHR vendors are really opponents/gatekeepers here. They don't benefit from you getting your data out of the EHR and in my experience they weren't really open to it.

Interoperability is really driven by either state/federal reporting requirements, or billing. And there is no incentive for EHR vendors or their client hospital systems to go beyond the exact minimum to get paid.

[nradov]

Epic has an extensive set of interoperability APIs, mostly based on open industry standards, which enable easy sharing of data across platforms. Is there something specific missing?

https://open.epic.com/

[pc86]

Pardon my bluntness but this is a bullshit brochure website.

I've worked with non-health system healthcare companies that have tried to work with Epic on interoperability. They are outright hostile to anyone being able to access any data in their systems unless it's the hospital customer (and even then they're not exactly helpful).

[nradov]

Could you be more specific about what part of the website is bullshit? I've used some of those APIs and they worked as documented.

Vendor hostility is only an issue if you actually need to work directly with the vendor. Most of them have no incentive to help other developers who aren't their customers. Why would they? If you're doing something new that requires active Epic cooperation then it's best to partner with a major Epic customer, and put a formal legal agreement in place.