subscription-service / faq

Frequently asked questions.

Is this really FOSS? What's the catch?

Yes. The Core tier is Apache 2.0, no time-bombed trial, no message quota, no nag screens, no phone-home. You can run it forever in production and never speak to us. The commercial tiers (Pro and Cloud) sell service and certification on top of the same code — see the pricing matrix.

What EHRs does it support?

Anything that speaks HL7 v2 over MLLP or exposes a pollable FHIR R4 endpoint. We ship vendor profiles for Epic, Meditech, Cerner (Oracle Health), athenahealth, and NextGen. If your EHR isn't on that list, write a profile — the community-template walks you through it.

What if my EHR has a quirk no profile handles?

Profiles are designed to grow. Each one is a YAML manifest plus StructureMaps; quirks are declarative entries pointing at strategy implementations the engine ships. Add the strategy as a built-in plugin PR, or drop in your own JAR. You don't have to fork the engine.

Can I run this on-prem? In my cloud?

Yes to both. The same image runs on plain Docker Compose, on k3s on a Raspberry Pi cluster, and on production EKS/GKE/AKS via the official Helm chart. Reference Terraform for AWS, GCP, and Azure lives in the subscription-service-examples repo. Capability gating in the Helm values means the same chart deploys cleanly to dev and prod.

How does FHIR Subscription differ from a webhook?

A FHIR Subscription is a standards-defined resource (R4 + Subscriptions Backport) that lets a downstream system declare what it wants to be notified about using FHIR search criteria — Patient?identifier=foo, Encounter?status=in-progress, etc. The server matches those criteria against new and updated resources and fires notifications via rest-hook, websocket, email, or message channels. Plain webhooks don't speak FHIR criteria, don't have a standard payload, and don't give you a portable contract across vendors. Subscriptions do.

Do I need HAPI FHIR if I already have my own FHIR server?

Not strictly — but the bundled HAPI is the default sink and the path we test most heavily. The MessageSink SPI lets you route transformed Bundles to any FHIR server (or to Kafka, S3, an HL7 outbound — anywhere). You can run subscription-service with our HAPI for outbound and your existing FHIR server for downstream consumers in parallel, or replace the sink entirely. See the plugins-spi docs for the contract.

What about HIPAA?

The Core code carries the technical controls HIPAA's Security Rule asks for: TLS in transit, OIDC auth, FHIR AuditEvent persistence, encryption at rest if you configure your storage that way. HIPAA compliance also requires a signed Business Associate Agreement, and that's a contract — not something software can give you. We sign BAAs at the Pro and Cloud tiers. If you run Core yourself, you sign the BAA with whoever's handling PHI in your stack.

Where do I get support?

Core users: FHIR community Zulip and quarterly virtual community calls. Pro users: business-hours email support with a same-business-day response SLA, plus a quarterly upgrade-readiness review. Cloud users: 24/7 on-call and we run the system. The GitHub issue tracker is for bugs and feature requests across all tiers.

Why not use Mirth Connect or Rhapsody?

Both are excellent products with established communities. subscription-service is narrower by design: it converts HL7 v2 to FHIR and fires FHIR Subscriptions. It's not a general-purpose interface engine. If you already have Mirth or Rhapsody handling your inbound v2 stream, point them at our MLLP port for the slice they don't handle. We aim to compose with existing interface engines, not displace them.

How does versioning and upgrade work?

Semantic versioning across the binary, the operator UI, and the plugin SPI. Backward-compatible changes ship in minor releases; breaking changes get a major. The plugin SPI is held stable across the lifetime of a major version. Helm chart values and Docker Compose env vars follow the same compatibility rules. Pro customers get a quarterly upgrade-readiness review.

Can I see what's coming?

Yes — the roadmap lives in OpenProject and a public-facing changelog ships on every release. Bigger pieces (FHIR R4B + R5 forward compat, additional ingest types, certified profiles) show up in the release notes when they ship. We don't pre-announce private commercial features.