← All articles

InterSystems HealthShare: Is the Platform Tax Worth It?

InterSystems occupies a unique position in healthcare IT. They built the database technology (Caché, now IRIS) that Epic runs on. That genealogy gives HealthShare a level of data access with Epic that no external integration engine can match. If you are a large Epic health system that needs deep analytics on clinical data, HealthShare may be the only platform that can get you there.

The question is whether that depth justifies the cost: ObjectScript developers ($180-250K salary, small talent pool), six-figure annual licensing, 6-12 month implementation timelines, and a proprietary technology stack that you cannot migrate away from without a full rewrite.

What HealthShare actually is

HealthShare is not an integration engine. It is a platform with three layers:

  1. Integration — HL7v2, FHIR, X12, CDA message routing and transformation
  2. Clinical Data Repository — a unified care record that aggregates patient data from multiple sources
  3. Analytics — population health reporting, quality measures, and dashboards

You can use just the integration layer, but you are paying for the full platform. Most HealthShare deployments use all three, which is where the value proposition is strongest.

The Epic connection advantage

This is the honest case for InterSystems. Because Epic's database is built on InterSystems' technology, HealthShare can access Epic data at a depth that goes beyond what FHIR APIs expose. Specific advantages:

  • Direct data access beyond the FHIR resource surface (with Epic's cooperation)
  • Shared data model understanding — InterSystems' team understands Epic's internal schemas
  • Tighter integration for analytics and population health workflows

If your use case requires data that Epic's FHIR API does not expose, and you cannot get it through HL7v2 feeds either, HealthShare may be the only path that does not require a custom arrangement with Epic.

For most other use cases — receiving ADT feeds, querying Patient/Encounter/Observation, sending CDS Hook cards — the FHIR API and HL7v2 feeds are sufficient, and HealthShare's Epic advantage is not relevant.

The ObjectScript problem

HealthShare transforms and business logic are written in ObjectScript, InterSystems' proprietary language descended from MUMPS. If your team writes TypeScript, Python, or Go, ObjectScript will feel alien.

The practical impact:

  • Hiring is harder. ObjectScript developers are a niche market. Expect $180-250K salary and longer hiring timelines.
  • Knowledge transfer is slower. Onboarding a new developer to ObjectScript takes 2-3 months, versus days for a JavaScript-based engine.
  • Code portability is zero. Your ObjectScript transforms are locked to InterSystems' platform.

Some HealthShare deployments mitigate this by using InterSystems' newer Python and JavaScript interop capabilities, but the core platform still assumes ObjectScript proficiency.

When HealthShare makes sense

  • You are a large Epic health system (500+ beds) that needs deep data access beyond FHIR APIs
  • You need a clinical data repository alongside your integration layer (not just a message pipe)
  • Population health analytics on integrated data is a primary use case
  • Your organization has InterSystems expertise or the budget for a 6-12 month consulting engagement
  • You run a national or regional health information exchange

When it does not

  • You need an integration engine, not a full data platform
  • You are a startup, growth-stage company, or small health system
  • Your team cannot absorb ObjectScript's learning curve
  • You want to avoid vendor lock-in to a proprietary stack
  • Time to first integration matters (HealthShare implementations take 6-12 months)
  • Budget is a primary constraint

What replacing HealthShare looks like

If you have HealthShare and are considering moving away (usually triggered by a contract renewal and sticker shock), here is what the replacement architecture typically looks like:

  • Integration layer: MedHook or Mirth Connect for HL7v2/FHIR message routing
  • Data repository: HAPI FHIR server for clinical data aggregation
  • Analytics: Your existing BI tools (Tableau, Looker, dbt) pointed at the FHIR server's database

This replaces HealthShare's three layers with three separate tools. You lose the integrated platform experience and the Epic depth advantage. You gain portability, a wider developer talent pool, and significantly lower licensing costs.

Is it worth migrating? Rarely, if HealthShare is working. The migration cost and risk usually outweigh the savings. Consider alternatives when the contract comes up for renewal, when you are expanding to a new use case that does not require HealthShare's depth, or when ObjectScript talent becomes a persistent hiring blocker.

Evaluating whether HealthShare is the right fit, or whether a lighter stack would serve you better? We have worked with both and can help you make the call.