Built from real interoperability work

We worked with FHIR servers, HL7 v2 interfaces, custom operations, healthcare integration platforms, and production clinical systems. Over time, much of our work became focused on building and maintaining HL7 → FHIR integrations.

During that work, we saw the same problems again and again.

Traditional interface engines were designed mainly around receiving, transforming, and routing messages. They solved an important problem and still run critical healthcare interfaces around the world.

Modern HL7 → FHIR projects, however, place different demands on integration teams. Transformation logic becomes more complex. Generic mapping logic gets mixed with organization-specific behavior. Reusable integration logic becomes difficult to organize and share across projects. Testing and debugging often depend on the running integration server instead of normal development tools.

As integrations grow, this becomes harder to maintain.

Too much time is spent working around integration tools instead of solving the actual interoperability problem.

The same problems appear in many projects

Over time, we realized that these problems were not unique to one project or one team.

Interoperability engineers repeatedly face the same challenges: complex mappings, duplicated transformation logic, difficult debugging, limited code reuse, local terminology, different identifiers, customer-specific workflow rules, retries, recovery, monitoring, and production support.

The hardest problems are usually the ones that differ from one healthcare organization to another.

One hospital may use its own patient identifiers. Another may use local codes. Another may have special workflow rules or different HL7 conventions.

A universal converter cannot solve all of these differences automatically.

At the same time, developers should not have to rebuild the same technical foundation for every new integration.

That became one of the main ideas behind FireSonic.

The platform we wanted to use ourselves

The platform handles the common work: HL7 v2 → FHIR transformation, message processing, durable persistence, FHIR delivery, recovery, validation, administration, and operational visibility.

Integration developers remain in control of the parts that are specific to their environment: local identifiers, terminology, normalization, enrichment, reconciliation, semantic rules, and workflow logic.

The goal is not to hide healthcare interoperability behind a black box.

The goal is to remove repetitive work and give developers control where they actually need it.

Interoperability is software development

We believe integration logic should be developed with the same engineering practices as the applications it connects.

With the FireSonic Developer SDK, integrations can be developed in a normal IDE using Java and Groovy.

Developers can debug interactively with breakpoints and full IDE tooling instead of repeatedly adding log statements and redeploying. They can write unit and integration tests with JUnit or Spock, keep code in Git, review changes through normal source-control workflows, validate builds in CI, and promote tested integrations through standard CI/CD pipelines.

Reusable logic can live in normal classes instead of being copied between scripts, channels, or projects.

The same integration code that is developed and tested locally can then run in the FireSonic runtime.

This development model became one of the central ideas behind the FireSonic Developer SDK.

More than message conversion

HL7 → FHIR interoperability is not only about creating structurally valid FHIR resources.

A Patient can be valid FHIR and still contain the wrong identifier.

An Observation can be valid but linked to the wrong Encounter.

A local code may need normalization.

A workflow can be technically valid and still be wrong in its clinical context.

This is why semantic validation and project-specific workflow logic are first-class parts of FireSonic.

The platform handles what can be standardized while leaving room for the clinical and operational rules that cannot.

Built for production

Healthcare interfaces run continuously.

Networks fail. Downstream systems become temporarily unavailable. Servers restart. Messages sometimes contain unexpected data.

These are normal production conditions.

FireSonic was designed with this in mind.

Incoming messages are durably persisted before processing begins. Transformation and delivery are separate stages. Failed deliveries can be retried. Processing can recover after restart.

Processing and delivery states remain visible to operators through the administration and monitoring tools.

Reliability is part of the platform instead of something every integration project has to build again.

Lightweight by design

Modern healthcare interoperability should not automatically require a large infrastructure footprint.

FireSonic was designed as a focused integration service with durable persistence, built-in administration, operational tooling, and straightforward deployment.

A basic deployment can remain simple.

When an environment requires greater throughput, availability, or operational scale, the architecture can grow with those requirements.

Complexity should be added because the environment needs it — not simply because the integration engine requires it.

Modernize, don't replace

HL7 v2 is still deeply embedded in hospitals, laboratories, medical devices, diagnostic systems, and other clinical infrastructure.

Those systems will not disappear simply because the industry is moving toward FHIR.

Nor should they have to.

At the same time, modern healthcare applications, data platforms, analytics systems, decision-support tools, and AI solutions increasingly use FHIR.

FireSonic was created to connect these two worlds.

The goal is not to replace systems that already work.

The goal is to make their data available to modern FHIR-based applications in a way that is reliable, maintainable, testable, and comfortable for software engineers to work with.

Sharing FireSonic with the community

FireSonic started as the platform we wanted to use ourselves.

Community Edition and the Developer SDK make that foundation available to other interoperability engineers and teams facing many of the same problems.

Real interoperability software improves through real implementations. Feedback, bug reports, integration experience, and contributions from the community help us continue improving FireSonic around the problems interoperability teams encounter in practice.