Hexion's Prescription for API Headaches: Solving the Common Mistake of Point-to-Point Integration in Healthcare

If you work in healthcare IT, you've probably seen it: a lab system wired directly to an EHR, a billing API hardcoded to a single payer, or a telehealth platform that only talks to one vendor. These point-to-point integrations feel fast to build, but they create a spiderweb of dependencies that break constantly. In this guide, we'll walk through why that pattern fails, and how to replace it with something that scales.

Who This Hurts Most — and What Goes Wrong

Point-to-point integration is tempting because it's simple. Two systems agree on a format, you write a connector, and data flows. But in healthcare, that simplicity unravels fast. When you connect ten systems point-to-point, you need 45 separate interfaces. Each one is a potential failure point. Every upgrade to one system can break every interface connected to it. We've seen clinics lose half a day of lab results because a single API endpoint changed its response format.

The groups that suffer most are IT teams at mid-sized hospitals and regional health information exchanges (HIEs). They lack the budget for enterprise integration platforms but still need to connect dozens of applications. Without a strategy, they end up with a tangled mess that's impossible to maintain. Security teams also feel the pain: each point-to-point connection is a separate attack surface, and auditing data flows becomes a nightmare.

What usually breaks first is the error handling. In a point-to-point setup, when one system goes down, the whole chain fails. There's no buffer, no retry logic, no way to reroute. A simple timeout in a lab interface can cascade into delayed diagnoses. And because each connection is custom, fixing one doesn't help the others. The result is a brittle system that requires constant firefighting.

What You Need Before You Start Redesigning

Before you rip out your existing integrations, you need a clear picture of what you're working with. Start with an inventory: list every system that exchanges data, the direction of flow, the format (HL7 v2, FHIR, custom JSON), and whether it's real-time or batch. This map will reveal the worst offenders — the connections that break most often or carry the most critical data.

Next, get buy-in from stakeholders. Point-to-point integration often grows because individual departments solve their own problems without coordination. You need a governance group that can enforce standards. This doesn't have to be a formal committee; a weekly 30-minute meeting with leads from IT, clinical informatics, and compliance can work. Without governance, you'll just rebuild the same mess.

You also need to understand your data models. Healthcare data is notoriously inconsistent. A patient's name might be split into first and last in one system and stored as a single string in another. Before you can route data through a central hub, you need a canonical model — a common language that all systems translate into. FHIR resources are a good starting point, but you'll need to define which profiles you use and how you handle optional fields.

Finally, assess your infrastructure. Do you have the capacity to run an API gateway or message broker? If you're cloud-based, services like AWS API Gateway or Azure API Management can handle this. On-premise teams might look at Kong or MuleSoft. The key is to choose something that can enforce authentication, rate limiting, and transformation without becoming a bottleneck.

Core Workflow: Moving from Point-to-Point to a Hub-and-Spoke Model

The central idea is to replace direct connections with a single integration layer — an API gateway or enterprise service bus (ESB) — that all systems talk to. Instead of 45 interfaces, you need 10 (one per system to the hub). Here's the step-by-step.

Step 1: Identify the most brittle connections

Look at your inventory and pick the three interfaces that fail most often or carry the most critical data. These are your pilot candidates. Don't try to migrate everything at once; that's a recipe for disaster. Start small, prove the pattern, then expand.

Step 2: Define a canonical data model

Map the data fields from each system to a common set of resources. For example, if you're connecting an EHR and a lab system, define a FHIR DiagnosticReport resource that includes all the fields both systems need. This model becomes the contract that every adapter must comply with.

Step 3: Build adapters for each system

Each system gets a small adapter that translates its native format into the canonical model and vice versa. The adapter runs on the system's side or in the gateway. It handles authentication, error mapping, and retries. Because the adapter only talks to the gateway, you can change the system without touching other adapters.

Step 4: Route through the gateway

Configure the gateway to receive messages from one adapter, apply any transformations or business rules (e.g., filter out test results that aren't yet finalized), and forward to the target adapter. The gateway also handles logging, monitoring, and alerting. If a target system is down, the gateway can queue the message and retry later.

Step 5: Test with parallel run

Run the old point-to-point connection and the new hub-and-spoke path simultaneously for a week. Compare outputs. This catches edge cases where your canonical model doesn't capture all the nuance. Once you're confident, cut over by disabling the old interface.

Tools and Setup Realities

No single tool fits every healthcare organization, but a few patterns emerge. For teams with cloud access, a managed API gateway is the easiest path. AWS API Gateway with Lambda adapters can handle HL7 v2 to FHIR transformation using open-source libraries like HAPI. Azure's API Management similarly supports custom policies for message transformation.

On-premise teams often turn to open-source gateways like Kong or Tyk. Both support plugins for authentication (OAuth2, JWT) and rate limiting. For message queuing, RabbitMQ or Apache Kafka can buffer traffic and ensure delivery even when downstream systems are slow. Kafka's log-based architecture is especially good for audit trails — every message is stored and replayable.

One reality check: adapters are not trivial. Even with a canonical model, you'll spend time handling quirks like optional fields, null values, and version differences. A lab system might send a result as a single string, while your canonical model expects separate components. You'll need to write transformation logic, and that code must be tested. Budget for this — it's often underestimated.

Another reality: governance is hard. Without someone enforcing the canonical model, departments will start adding custom fields and bypassing the gateway. We've seen teams build a beautiful hub, only to have a new vendor integration go point-to-point because the project was urgent. The gateway must be the only path for data exchange, or it won't work.

Variations for Different Constraints

Not every healthcare organization can afford a full ESB or API gateway. Here are three common scenarios and how to adapt.

Small clinic with limited IT

If you have fewer than five systems, a lightweight approach can work. Use a simple message broker like RabbitMQ running on a single server. Each system sends and receives messages through a standardized JSON schema. You can skip the canonical model and instead agree on a common format upfront. The trade-off is less flexibility — adding a new system later may require changing all adapters.

Large hospital with legacy systems

Legacy systems often speak HL7 v2 over MLLP. An integration engine like Mirth Connect (open-source) can act as your hub. It supports HL7 v2, FHIR, and custom formats, and can transform messages in-flight. Mirth runs on-premise and has a visual interface for building channels. The downside is that it's not as scalable as a cloud gateway, but for a single hospital, it's proven.

Health information exchange (HIE) with many participants

HIEs need to handle many different data sources and strict privacy rules. Here, a FHIR-based exchange with SMART on FHIR authorization is standard. Use a gateway like HAPI FHIR Server as the central repository. Each participant registers their endpoints and shares data through the FHIR API. The gateway enforces consent management and audit logging. This approach is more complex but scales to hundreds of organizations.

Pitfalls and Debugging: What to Check When It Breaks

Even with a hub-and-spoke design, things will go wrong. Here are the most common failures and how to troubleshoot.

Message transformation errors

Your adapter might fail to map a field because the source system sent unexpected data — a date in the wrong format, a missing required field, or a value that exceeds the maximum length. Log every transformation failure with the raw message and the error details. Build a dashboard that shows these errors in real time. Most gateways support custom logging; use it.

Authentication and authorization issues

When you move to a central gateway, every system needs to authenticate. If a system's credentials expire or its IP address changes, the connection drops. Use service accounts with long-lived tokens, but rotate them regularly. Test your token refresh logic. Also, ensure the gateway's access control lists (ACLs) are updated when new systems join.

Latency and timeout

Adding a gateway introduces a hop, which can increase latency. If a downstream system is slow, the gateway might time out. Set realistic timeout values — start with 30 seconds for synchronous calls, and use asynchronous messaging for long-running processes like image transfers. Monitor p95 latency and alert if it exceeds your threshold.

Data consistency

When a message fails after partial processing, you can end up with inconsistent data. For example, a lab result might be stored in the gateway's log but never reach the EHR. Implement idempotency keys so that retries don't create duplicates. Use a two-phase commit pattern only if absolutely necessary; it's complex and slow. Instead, design your adapters to be idempotent — checking for existing records before inserting.

Common Questions and Next Steps

We often hear the same questions from teams starting this journey. Here are direct answers.

Do we need to migrate everything at once?

No. Start with the three most painful connections. Prove the pattern, then expand. A phased migration reduces risk and lets you learn from mistakes.

What about real-time requirements?

For real-time data like vital signs monitoring, a gateway can still work if it's low-latency. Use a lightweight protocol like WebSocket or MQTT instead of HTTP polling. Test your gateway's throughput under load — many open-source gateways can handle thousands of messages per second on modest hardware.

How do we handle vendor lock-in?

Use open standards like FHIR and open-source tools where possible. Even if you choose a commercial gateway, ensure it supports standard protocols (REST, HL7, FHIR) so you can switch later. Avoid custom extensions that tie you to one vendor.

Your next move should be practical: pick one interface from your inventory and build a pilot adapter this week. Map the data, set up a test gateway, and run it in parallel. The goal is not perfection — it's learning what works in your environment. Once you see the pattern succeed, you'll have the confidence to expand.