Thinking Through FHIR Integration Decisions

When a new clinical application that relies on FHIR-based APIs is being introduced, integration discussions can move quickly. The vendor explains how their product connects to the EHR, internal teams review what is required, and before long the organizations may be moving toward a setup simply because it feels familiar, standard, or easiest to advance.

That is exactly where it helps to slow down.

In most organizations, there is an expectation that new applications will connect through the integration engine. It is also common for vendors to recommend a direct connection based on how their product is most efficiently implemented. Both are reasonable starting points, but neither should decide the approach on its own.

What matters more is what the organization will need once the application is live. A connection that seems simple during setup may be harder to monitor, support, or adopt later. A connection that goes through the engine may add useful control, or it may add very little beyond another step in the path. The point is not to defend one model over the other. It is to think through the trade-offs before the design is locked in.

What should guide the decision

Before finalizing how a new application should be connected, it helps to step back and focus on a few key things.

👀 When something goes wrong, who will be responsible for investigating and resolving it?

💭 Are there differences in data structure or interpretation that need to be handled?

⚖️ Are there organizational and regulatory requirements for security, access, and audit?

🏥 How does this decision affect consistency across integrations as the environment grows?

If the integration engine does not support the connection type being proposed, the decision path changes early. In those cases, the focus shifts to how the connection will be implemented and supported, rather than whether it should pass through the engine.

Comparing the connection approaches

With those questions in mind, the next step is to look at how the connection could be designed for the new application. In most cases, the setup falls into one of two patterns. Both can work. The more important difference is how the connection will be supported and managed once the application is in use.

Direct Connection

In this model, the application connects directly to the EHR using the vendor’s supported FHIR-based integration approach. The connection path is usually simpler and may reduce the amount of internal build work during implementation. In many cases, the vendor provides defined setup guidance and support the connection as part of their standard deployment model.

🧩 Common characteristics:

• Vendor provides defined integration approach
• Lower internal build effort during implementation
• Direct connection between the application and the EHR
• Aligns closely with the vendor’s support and testing model

🔎 What to keep in mind:

• Transaction visibility may be limited without vendor involvement
• Troubleshooting may depends on vendor logs or support
• Security and access controls may differ from existing patterns
• EHR API or application changes may require external coordination

Engine-mediated connection

In this model, the connection is routed through the integration engine, which sits between the application and the EHR. Depending on the design, the engine may take on a more active role or operate mainly as a control layer that passes requests through.

In some cases, the engine manages transformation, routing, and validation. In others it is used more selectively for authentication, logging, and monitoring while allowing the request to move between the application and the EHR. This can be useful when transformation is not needed at the start but may become necessary later.

🔧 Common characteristics:

• Integration team builds and configures the connection in the engine
• Requests and responses are monitored centrally
• Transactions can be traced without relying on the vendor
• Authentication, access control, and logging follow established patterns

📍 What to keep in mind:

• Additional build effort is required, even as a pass through layer
• The connection path includes another potential failure point
• API traffic may have cost or capacity implications
• More coordination with the integration team is required

Bringing the decision together

Choosing how a FHIR-based application connects to the EHR is less about selecting a preferred model and more about understanding how each option fits within the broader environment. A direct connection may make sense when the approach is clear, support expectations are well understood, and the organization is comfortable managing the connection outside the engine. An engine-mediated design may make more sense when visibility, consistency, security controls, or future flexibility carry more weight.

The important thing to avoid is treating either path as automatic. "Everything through the engine" is not always the right answer, and "the vendor prefers it this way" is not enough on its own.

When a direct connection is chosen, it helps to treat it as a deliberate decision rather than a default. That means being clear about monitoring, support ownership, security requirements, and how future changes will be handled.

As more applications are introduced, these decisions start to shape how manageable the overall integration landscape becomes. Taking the time to think them through early makes it easier to support each connection well after implementation is complete.