DEV Community: Om Jariwala

Building Telehealth That Handles Latency, EHR Integration, and HIPAA Safeguards

Om Jariwala — Mon, 19 Oct 2026 08:47:18 +0000

A telehealth app can pass every demo and still fail in production. The video freezes on a patient's rural 4G connection. The EHR sync silently drops a medication update. A debug log captures a diagnosis in plain text.

Healthcare software is judged on a different scale than most products. A glitch isn't just a bad review, it's a clinical risk and a compliance risk. Here are the three problems that cause the most trouble, and how to design for them from day one.

1. Latency: design for the worst network, not the best

A video visit with a 2-second delay isn't a consultation, it's two people talking over each other. Most of your patients won't be on office fiber.

Use WebRTC, but plan for what it doesn't solve.

Run TURN servers. Direct peer-to-peer fails behind many corporate and mobile NATs. Without TURN fallback, those users simply can't connect.
Use an SFU for anything beyond 1:1. Group visits (patient, doctor, interpreter, family member) don't scale on mesh topologies.
Deploy media servers close to users. Region-aware routing often does more for perceived quality than any codec tuning.
Degrade gracefully. When bandwidth drops, reduce video resolution first, then fall back to audio-only. Audio is what carries the consultation.

Add a pre-call check so problems surface before the visit starts:

async function preCallCheck() {
  const pc = new RTCPeerConnection({ iceServers });
  pc.createDataChannel("probe");
  await pc.setLocalDescription(await pc.createOffer());

  const stats = await collectIceStats(pc); // RTT, candidate types
  const usingRelay = stats.selectedCandidateType === "relay";

  return {
    rttMs: stats.rtt,
    usingRelay,
    recommendation: stats.rtt > 300 ? "audio-only" : "video",
  };
}

Measure what matters in production: time-to-first-frame, reconnection rate, packet loss, and join-failure rate. Track them per region and per network type, because averages hide the patients who struggle most.

2. EHR integration: assume the other system is slow, strict, and inconsistent

Integrating with EHRs is less about writing API calls and more about surviving their quirks.

Standardize on FHIR where you can. HL7 FHIR R4 with SMART on FHIR (OAuth 2.0) is the most realistic path to interoperability. Expect to still handle HL7 v2 messages and vendor-specific extensions for older systems.

Never block the visit on an EHR call. Treat EHR writes as asynchronous:

# Visit ends -> enqueue, don't call the EHR inline
def on_visit_completed(visit):
    outbox.add(
        type="encounter.create",
        idempotency_key=f"visit-{visit.id}",
        payload=build_fhir_encounter(visit),
    )

# Worker: retries with backoff, safe to run twice
def process_outbox(item):
    try:
        ehr_client.post("/Encounter", item.payload,
                        headers={"If-None-Exist": item.idempotency_key})
        item.mark_done()
    except TransientError:
        item.retry_with_backoff()
    except ValidationError as e:
        item.send_to_dead_letter(e)  # needs human review

The patterns worth adopting:

Outbox pattern. Write the clinical record and the sync job in the same database transaction so nothing is lost between them.
Idempotency keys. Retries are guaranteed, so duplicate encounters must be impossible.
Dead-letter queues with alerting. A failed sync of a prescription or note should page someone, not disappear.
Patient matching with care. Matching on name and date of birth alone creates wrong-chart risk. Use the EHR's identifiers (MRN, FHIR Patient IDs) and treat ambiguous matches as a manual review case.
Map data explicitly. Keep a versioned mapping layer between your internal model and FHIR resources, so one EHR's quirk doesn't leak into your whole codebase.

3. HIPAA safeguards: compliance is a system property, not a library

No framework makes you "HIPAA compliant" on its own. Compliance combines technical controls, policies, and agreements. On the technical side, the HIPAA Security Rule's safeguards translate into concrete engineering work:

Safeguard	What it looks like in practice
Access control	Role-based access, unique user IDs, MFA, automatic session timeout
Audit controls	Immutable logs of who accessed which record, when, and why
Integrity	Checksums, versioned records, protection against silent modification
Transmission security	TLS 1.2+ everywhere, DTLS-SRTP for WebRTC media
Encryption at rest	Managed keys (KMS), per-environment separation, rotation

A few mistakes show up repeatedly:

PHI in logs and error trackers. Scrub request bodies, and never log full payloads from clinical endpoints.
PHI in push notifications and emails. "Your lab result for diabetes is ready" leaks information on a lock screen. Keep notifications generic.
Recording by default. Store only what you need (the minimum necessary standard), with explicit consent flows.
Non-production environments with real data. Use synthetic or de-identified data in dev and staging.
Missing Business Associate Agreements. Every vendor that touches PHI (cloud, video, SMS, analytics) needs a BAA, and some tools you rely on may not offer one.

A simple audit log middleware is a good start:

app.use("/api/patients/:id", async (req, res, next) => {
  res.on("finish", () => {
    auditLog.write({
      actor: req.user.id,
      role: req.user.role,
      action: `${req.method} ${req.route.path}`,
      patientId: req.params.id,
      outcome: res.statusCode,
      ip: req.ip,
      at: new Date().toISOString(),
    });
  });
  next();
});

Putting it together

These three concerns pull against each other. Encryption and audit logging add overhead, EHR sync adds failure modes, and real-time video leaves no room for either. Teams that handle this well do a few things consistently:

Decouple real-time from record-keeping. The video path stays fast, and clinical documentation flows through reliable async pipelines.
Build observability in early. You can't fix latency or sync failures you can't see.
Treat compliance as part of the architecture review, not a checklist before launch.

Patients never see any of this. They only notice whether the call connected, whether their doctor had their history, and whether they felt safe. That's what trust in telehealth is built on.

What's the hardest part of telehealth engineering you've run into: media quality, EHR quirks, or compliance? Share it in the comments.

Building EHR Integrations: 6 Things to Get Right Before Writing Code

Om Jariwala — Wed, 14 Oct 2026 12:11:52 +0000

Connecting an application to an Electronic Health Record (EHR) system sounds straightforward.

Find the API. Authenticate. Fetch patient records. Send updates. Done.

Except healthcare integrations rarely work that way in practice.

You might connect successfully but receive incomplete data. A request might time out and create duplicate records when retried. Two systems might use different formats for the same clinical information. Or your application might retrieve patient data without enforcing the right access permissions.

These problems often start before the first line of integration code is written.

If you're building a telehealth platform, patient portal, healthcare SaaS product, or clinical application, here are six things to get right before starting an EHR integration.

1. Understand the Data Flow Before Choosing the API

Start by identifying what information your application needs and where that information comes from.

For example, a telehealth platform might need to:

Retrieve patient demographics and medical history.
Read medications, allergies, and clinical observations.
Access encounter details.
Send consultation notes to the EHR.
Create or update supported clinical records.

These workflows can involve different API resources, permissions, and write operations.

Before implementation, document three things for every data type:

Source: Which system owns the information?
Direction: Does your application read, write, or synchronize it?
Timing: Does it need to be available immediately, periodically, or only when requested?

This helps establish the integration boundary and prevents the application from treating every connected system as an interchangeable database.

A useful rule: define the workflow first, then identify the API operations needed to support it.

2. Understand FHIR and the EHR's Actual Implementation

FHIR (Fast Healthcare Interoperability Resources) provides a standard for exchanging healthcare information.

It defines resources such as:

Patient — patient demographics and identifying information.
Observation — measurements and clinical observations.
Encounter — a healthcare interaction.
Condition — a health condition or diagnosis.
MedicationRequest — a medication order or prescription request.
DiagnosticReport — diagnostic findings and report information.

FHIR makes interoperability easier, but it doesn't guarantee that every EHR implements every resource in the same way.

One vendor may support a particular resource but restrict certain operations. Another may require specific profiles, search parameters, or authorization scopes.

Before writing code, check:

Which FHIR version is supported?
Which resources and operations are available?
Are there vendor-specific implementation guides?
Which fields are mandatory?
What search parameters and pagination behavior are supported?
Which authorization scopes are required?

Also review the vendor's sandbox and test data, where available.

Don't build against the FHIR specification alone. Build against the specification and the target EHR's implementation.

3. Design Patient Matching and Data Mapping Carefully

One of the most important integration decisions is determining whether two records represent the same patient.

Your application may use an internal patient ID, while the EHR uses its own identifier. Names and dates of birth alone may not reliably establish identity.

A safer design uses the appropriate identifiers and matching rules agreed upon for the integration.

For example, maintain a mapping between your internal patient record and the corresponding identifier in the external system. Account for multiple identifiers where the workflow requires them.

Data mapping deserves the same attention.

A field in your application may not correspond directly to a field in the EHR. Clinical concepts may use standardized codes, specific units, or vendor-defined profiles.

Before implementing transformations, establish:

Identifier mapping rules.
Field-level mappings.
Required and optional values.
Terminology and unit handling.
Missing or conflicting data behavior.
Validation rules for incoming and outgoing records.

Avoid silently filling gaps with assumptions.

If a record cannot be matched confidently, the system should follow a defined exception-handling process rather than attaching the information to a potentially incorrect patient.

4. Plan Authentication, Authorization, and Audit Logging

An integration that can retrieve patient information must also enforce appropriate access restrictions.

Depending on the EHR and application, authentication may use OAuth 2.0, SMART on FHIR, or another supported mechanism.

But successful authentication doesn't mean every request is authorized.

Consider these implementation details:

Token management

Store credentials securely.
Handle token expiration and refresh where supported.
Avoid exposing access tokens in logs or client-side code.
Request only the scopes the application needs.

Authorization

Enforce permissions on the server.
Verify access to the requested patient and resource.
Separate user-authorized access from background service operations.
Handle revoked access and failed authorization explicitly.

Audit logging

Record relevant access and modification events.
Capture enough context to investigate problems.
Restrict access to audit logs.
Avoid unnecessarily copying protected health information into log messages.

For US healthcare applications subject to HIPAA, these controls should be designed in the context of the applicable security and privacy requirements. An API integration alone does not establish compliance.

5. Make Retries Safe and Handle Failures Explicitly

External systems can be slow or unavailable. Requests can time out, rate limits can be reached, and network connections can fail.

The difficult part is that a timeout doesn't always tell you whether the operation succeeded.

Imagine your application sends a request to create an encounter-related record. The EHR processes it, but the response never reaches your application.

Your application retries the request.

Without suitable safeguards, you may create a duplicate.

A robust integration should consider:

Timeouts: Avoid requests waiting indefinitely.
Retry policies: Retry transient failures with bounded exponential backoff and jitter.
Rate limits: Respect vendor limits and retry guidance.
Idempotency: Use supported idempotency mechanisms or another reliable duplicate-prevention strategy.
Error classification: Distinguish temporary failures from invalid requests and authorization errors.
Reconciliation: Detect and resolve records that may have been missed or processed inconsistently.

Not every API supports idempotency keys, so the implementation must follow the actual vendor's capabilities.

For workflows that can tolerate asynchronous processing, background jobs and queues can help separate user-facing requests from external-system availability.

The goal isn't to prevent every failure. It's to make failures predictable and recoverable.

6. Test the Complete Workflow, Not Just Individual Endpoints

A successful API response proves that one request worked. It doesn't prove that the entire healthcare workflow is correct.

Suppose your application can retrieve a patient record successfully. You still need to validate what happens when the record is incomplete, the patient has multiple identifiers, authorization changes, or a downstream system becomes unavailable.

A useful test plan includes:

Test area	What to validate
Data mapping	Fields, identifiers, codes, and units are mapped correctly.
Authorization	Users and services cannot access unauthorized records.
Pagination	Large result sets are processed without missing records.
Error handling	Timeouts, rate limits, and server errors are handled safely.
Duplicate prevention	Retried operations don't create unintended duplicates.
Data freshness	Updates and synchronization delays are handled as expected.
Audit logging	Relevant access and modification events are recorded.
End-to-end workflows	Data moves correctly across the complete user journey.

Use vendor sandboxes and synthetic test data where available. Test against realistic edge cases, not only successful responses.

Also verify what happens when an integration is disconnected, credentials expire, or a vendor changes its API behavior.

These scenarios often reveal issues that simple endpoint tests miss.

A Practical Checklist Before Development

Before committing to an EHR integration, make sure you can answer these questions:

[ ] Do we know which workflows the integration must support?
[ ] Have we confirmed the target EHR's API capabilities and supported FHIR version?
[ ] Have we documented data mappings and patient-matching rules?
[ ] Are authentication scopes and authorization rules defined?
[ ] Do we have a plan for timeouts, retries, duplicate prevention, and reconciliation?
[ ] Have we defined integration tests and end-to-end acceptance criteria?

If several answers are still unclear, the next step is requirements discovery, not more code.

Final Thoughts

EHR integration is not simply an API task. It sits at the intersection of data modeling, identity, security, clinical workflows, and distributed-system reliability.

FHIR gives development teams a shared foundation, but reliable interoperability still depends on understanding the systems on both sides of the connection.

The best time to discover an identifier mismatch, missing permission, or unsupported API operation is before the integration becomes a dependency for your entire product.

Map the workflow. Verify the API. Define the data rules. Plan for failure. Then start coding.

If you're building a healthcare product, these decisions can make the difference between an integration that works in a demo and one that holds up in real-world use.

Your Healthcare Voice AI Agent Needs a Compliance Gate (Before It Costs You $50,000)

Om Jariwala — Tue, 13 Oct 2026 05:21:30 +0000

An $800 voice agent cost a healthcare founder $50,000.

I heard this directly from him last week. The agent worked. The voice was natural and the integration was clean. It had no rules for how often it could call the same patient or during which hours. It called the same people repeatedly, some calls landed outside permitted hours, and one complaint turned into a $50,000 bill.

Nothing crashed, and no model misbehaved. This was an engineering omission, and it's the kind we can prevent.

Here's how to design voice agents so that doesn't happen.

The core principle: the model never decides if a call is allowed

LLMs are good at conversation. They are a bad place to enforce legal constraints. A prompt that says "don't call more than once a day" is a suggestion, not a control.

Compliance has to live in deterministic code that runs before the agent is ever invoked.

Trigger (form abandoned / checkout dropped)
        │
        ▼
 ┌──────────────────┐
 │  Call scheduler  │  queue + delay (e.g. 15-20 min)
 └────────┬─────────┘
          ▼
 ┌──────────────────┐
 │ COMPLIANCE GATE  │  consent, DNC, time window,
 │ (deterministic)  │  frequency caps, call type
 └────────┬─────────┘
     deny │ allow
   ┌──────┘   │
   ▼          ▼
 requeue   Voice agent ──► tools (CRM/EHR, SMS, human handoff)
 or drop        │
                ▼
          Audit log (every decision, every call)

If the gate says no, the call is requeued for the next valid window or dropped. The agent never gets a vote.

The gate

from datetime import datetime, timedelta
from zoneinfo import ZoneInfo

MAX_CALLS_PER_DAY = 1
MAX_CALLS_PER_WEEK = 3
# Conservative window. Federal rules set the outer limit and
# some states are stricter. Confirm with counsel.
WINDOW_START, WINDOW_END = 9, 19  # recipient-local hours

def can_call(patient, call_log, call_type, now_utc=None):
    now_utc = now_utc or datetime.now(ZoneInfo("UTC"))
    local = now_utc.astimezone(ZoneInfo(patient.timezone))

    if patient.do_not_call or not patient.has_consent(call_type):
        return False, "no_consent_or_dnc"

    if not (WINDOW_START <= local.hour < WINDOW_END):
        return False, "outside_calling_window"

    day_ago = now_utc - timedelta(days=1)
    week_ago = now_utc - timedelta(days=7)
    mine = [c for c in call_log if c.patient_id == patient.id]

    if sum(1 for c in mine if c.at > day_ago) >= MAX_CALLS_PER_DAY:
        return False, "daily_cap"
    if sum(1 for c in mine if c.at > week_ago) >= MAX_CALLS_PER_WEEK:
        return False, "weekly_cap"

    return True, "ok"

A few details that matter more than they look:

Use the recipient's timezone, not the server's. A form filled at 3 a.m. their time gets queued, not called.
Pass call_type. Marketing and transactional calls have different consent rules and should use separate numbers.
Return a reason code. You'll want it in the audit log.

Concurrency: your caps are only as good as your locking

A naive check-then-call has a race condition. Two workers pick up the same patient at the same moment, both see zero calls, and both dial.

Make the check and the "reserve a slot" step atomic:

# Pseudocode: reserve before dialing, release on failure
with db.transaction():
    ok, reason = can_call(patient, call_log_for(patient), call_type)
    if not ok:
        audit.log(patient.id, "denied", reason)
        return
    call_log.insert(patient_id=patient.id, at=now, status="reserved")
# dial only after the reservation commits

Use a unique constraint or row-level lock per patient so duplicate triggers (webhook retries are common) can't cause duplicate calls. Make your trigger handlers idempotent.

Keep PHI out of the conversation

Personalization is what makes these agents effective. The agent that knows where the patient left off converts far better than a generic script. But the personalization layer is also where privacy leaks happen.

Give the agent only what it needs. First name and form progress, not the full record. Don't put diagnoses in the prompt or tool results unless required.
Add an output check. Scan agent responses for restricted content before they reach speech, and have the agent fall back to "I can't discuss that on this call" on a match.
Redact logs and transcripts. Call recordings and transcripts are PHI too. Treat them that way in storage and access control.

Audit everything

When a complaint arrives, your answer depends on your records. Log:

Every gate decision, with the reason code
Consent source and timestamp
Call start, end, outcome, and which number was used
Handoffs to a human

If you can't show why a call was allowed, you can't defend it.

Infrastructure checklist

BAA coverage for every component that touches patient data: LLM provider, voice platform, telephony, transcription, storage, logging. Some vendors only offer coverage on certain tiers or via add-ons, so verify each one in writing.
Branded, verified numbers to avoid spam labeling, and separate numbers for marketing and transactional calls.
Instant opt-out handling that updates the consent store immediately.
Human handoff available on every call.

Does it work? A real deployment

We built this pattern for a US telehealth company that acquires patients through paid social ads. A long intake form plus a payment step meant many people dropped off before paying.

The agent calls roughly 15 to 20 minutes after drop-off. It answers questions using the patient's form progress (pulled from their EHR), sends checkout links or discounts by SMS or email, shares testimonials, and hands off to a human on request.

It recovered about 10% of abandoned checkouts and was rolled out across multiple brands. The gate, caps, privacy controls, and audit log are what let it run at that scale without incident.

Takeaways

Integration is easy. Compliant integration is the actual project.
Never let the model enforce legal rules. Put a deterministic gate in front of it.
Make caps race-proof with atomic reservations and idempotent triggers.
Minimize and redact PHI in prompts, outputs, and logs.
Verify BAA coverage across the whole stack, in writing.
Hire for domain experience, not just the lowest quote. The $800 build is rarely the real price.

I build compliant AI and telehealth systems at Enacton, with HIPAA and calling-rule controls designed in from day one. Planning a voice AI project in healthcare? Let's talk before you launch, not after.

In 2026, These 6 Factors Determine Whether Your Epic Integration Costs $25K or $250K+

Om Jariwala — Fri, 09 Oct 2026 10:07:24 +0000

If you're building a healthcare SaaS product, integrating with Epic EHR is a challenge you may eventually need to solve.

At first, it might sound straightforward:

Connect to Epic's APIs.
Fetch patient data.
Map it to your application's data model.
Ship the integration.

But production healthcare integrations rarely stop there.

You'll need to account for authentication, FHIR resource mapping, clinical workflows, customer-specific configuration, security reviews, testing, and ongoing maintenance.

Depending on the scope, an Epic integration can become a substantial engineering project.

So, what actually drives the cost?

Let's break it down from a software engineering perspective.

First, What Should You Budget?

The following ranges are illustrative planning estimates, not official Epic pricing or independently verified market averages.

Integration scope	Illustrative budget
Basic, read-only data integration	$25K–$50K
Multiple resources and workflows	$50K–$100K
Complex, bidirectional clinical workflows	$100K–$250K+

These estimates assume a project-based implementation. Actual costs depend on engineering rates, the number of workflows, customer requirements, deployment complexity, and the scope of production support.

The important distinction is that connecting to an API is not the same as delivering a production-ready EHR integration.

Here are the six factors that influence the engineering effort.

1. FHIR Resource Coverage and Data Mapping

The first question is: What data does your application actually need?

A basic integration might retrieve patient demographics. A more complex integration could require:

Patient
Practitioner
Encounter
Condition
MedicationRequest
AllergyIntolerance
Observation
DiagnosticReport
Appointment
DocumentReference

FHIR provides standardized resource models, but it doesn't eliminate implementation differences between systems.

Your application still needs to understand how the source data maps to your internal domain model.

For example, an Observation resource might represent a vital sign, a laboratory result, or another clinical measurement. Your application needs to interpret its codes, units, status, timestamps, and references correctly for the intended workflow.

You may also encounter:

Missing or optional fields
Different coding systems
References to other resources
Pagination and large result sets
Customer-specific configuration
Differences in supported FHIR capabilities

What does this mean for cost?

Every additional resource type can introduce mapping, validation, and testing work.

The complexity increases further when resources are linked together and your application needs to preserve clinical meaning across those relationships.

Engineering takeaway: Define the required resources, fields, relationships, and expected data quality before estimating the integration.

2. Read-Only Access vs. Bidirectional Workflows

There is a significant difference between reading data from an EHR and writing data back to it.

A read-only integration might look like this:

Epic
  |
  | FHIR API
  v
Integration Service
  |
  | Normalize and validate
  v
Healthcare SaaS Application

Your service retrieves authorized data, transforms it into your internal model, and makes it available to your application.

Now consider a bidirectional workflow:

Epic <----> Integration Service <----> SaaS Application

Your application may need to create or update supported resources, depending on the use case and the customer's configuration.

That introduces additional engineering concerns:

Write permissions and authorization scopes
Validation before submitting data
Handling rejected or partially processed requests
Duplicate submissions and retry behavior
Idempotency where applicable
Conflict detection and reconciliation
Audit trails and failure recovery

For example, suppose your application submits a clinical observation, but the request times out before your service receives a response.

Did Epic process the request?

Blindly retrying could create duplicate data if the operation isn't safely idempotent.

Your integration needs an explicit strategy for uncertain outcomes.

Also, don't assume every FHIR resource supports every operation. Available operations, permissions, and implementation behavior depend on the relevant Epic environment and API configuration.

Engineering takeaway: Estimate each workflow separately. Read operations, write operations, and synchronization are different engineering problems.

3. FHIR Doesn't Eliminate Authentication and Interoperability Work

Using FHIR is a good starting point, but it doesn't make every EHR integration plug-and-play.

Your team still needs to implement the authentication and authorization flow required by the specific integration.

Depending on the application and environment, this may involve OAuth 2.0, SMART on FHIR, or other supported authorization patterns.

Typical implementation concerns include:

Obtaining and refreshing access tokens where applicable
Managing token expiration
Requesting the appropriate scopes
Handling 401 Unauthorized and 403 Forbidden responses
Respecting API limits and retry guidance
Validating resource schemas
Supporting pagination
Handling 4xx and 5xx responses
Logging failures without exposing protected health information

A robust integration also needs observability.

For example, track request failures, latency, retry counts, synchronization delays, and resource-processing errors.

Avoid logging access tokens or sensitive patient data simply to make debugging easier.

What does this mean for cost?

A prototype may only need a successful API request.

A production service needs predictable behavior when tokens expire, requests fail, upstream services become unavailable, or data arrives in an unexpected format.

Engineering takeaway: Budget for failure handling and observability, not just the happy path.

4. Customer Onboarding and Environment-Specific Configuration

Building the integration is only part of delivering it to a healthcare customer.

The implementation may also require environment-specific configuration, technical coordination, testing, and customer approval.

Depending on the project, this can include:

Confirming API and resource availability
Configuring application access
Coordinating authentication and permissions
Completing security and technical reviews
Validating data mappings
Testing against the customer's environment
Supporting user acceptance testing
Coordinating production deployment

A workflow that works in a development environment isn't automatically ready for a customer's production environment.

The customer may have different configuration requirements, permissions, data availability, or workflow expectations.

If you support multiple customers, you also need to decide which parts of the integration are reusable and which require customer-specific configuration.

For example:

Shared Integration Platform
    |
    +-- Customer A configuration
    |
    +-- Customer B configuration
    |
    +-- Customer C configuration

A configurable architecture can reduce duplicated work. However, customer onboarding, validation, and troubleshooting may still require dedicated effort.

Engineering takeaway: Separate the cost of building the integration platform from the cost of implementing and supporting each customer.

5. Security, Privacy, and Compliance Requirements

Healthcare integrations handle sensitive data, so security needs to be part of the architecture from the beginning.

Depending on your role, data flows, and applicable obligations, the project may require controls such as:

Encryption in transit and at rest
Least-privilege access controls
Secure credential and secret management
Audit logging
Data retention and deletion policies
Tenant isolation
Incident detection and response
Secure development and deployment practices
Appropriate contractual and compliance documentation

For US healthcare use cases, HIPAA-related requirements may also apply. The exact obligations depend on the organizations involved, the data being handled, and the nature of the service.

These requirements affect more than infrastructure.

They can influence application architecture, database design, logging, monitoring, access policies, testing, and operational procedures.

For example, a centralized logging system can be useful for troubleshooting, but it should not inadvertently collect unnecessary protected health information.

Similarly, a multi-tenant SaaS platform needs a clear strategy for preventing one customer's data from becoming accessible to another.

Engineering takeaway: Include security engineering, compliance-related implementation, and verification in the project estimate rather than treating them as post-launch tasks.

6. Testing, Production Operations, and Long-Term Maintenance

The integration isn't finished when the first successful request reaches production.

You still need to verify that it behaves correctly under real operating conditions.

A production testing strategy might include:

Unit tests for resource mapping
Integration tests for API interactions
Contract and schema validation
Authorization and permission tests
Negative tests for invalid requests
Retry and timeout tests
Duplicate-processing tests
Regression tests for existing workflows
End-to-end workflow validation

Clinical data mapping deserves particular attention.

A request can return a technically valid FHIR response while your application still interprets the underlying data incorrectly.

Testing therefore needs to verify both technical correctness and the expected behavior of the application workflow.

After launch, ongoing work may include:

Monitoring failed requests
Investigating customer-reported issues
Updating dependencies
Reviewing API and configuration changes
Maintaining compatibility
Responding to security findings
Supporting additional resources and workflows
Revalidating behavior after code changes

Not every project will require the same maintenance effort, but none should assume that production support is free.

Think in terms of total cost of ownership

Instead of estimating only the initial development effort, use a broader model:

Total Integration Cost =
Initial Engineering + Testing and Validation + Security and Compliance Work + Customer 
Implementation + Go-Live Support + Ongoing Maintenance

This is a planning framework, not a literal pricing formula. Each category should be estimated using the actual scope and expected effort.

Engineering takeaway: Distinguish one-time implementation costs from recurring operational costs.

How to Estimate an Epic Integration More Accurately

Before assigning a budget, document the integration scope.

A practical starting checklist:

[ ] Data scope: Which FHIR resources and fields are required?
[ ] Workflow scope: Is the integration read-only, write-enabled, or bidirectional?
[ ] Authorization: Which authentication flow, scopes, and permissions are needed?
[ ] Data mapping: What transformations, terminology mappings, and validations are required?
[ ] Customer scope: How many environments and customer-specific configurations must be supported?
[ ] Security: Which technical controls and compliance obligations apply?
[ ] Testing: What integration, regression, and end-to-end tests are required?
[ ] Operations: Who owns monitoring, incident response, and ongoing maintenance?

Once these requirements are clear, estimate the effort for each workstream.

You can then build a budget from engineering hours, implementation costs, external dependencies, contingency, and expected operational expenses.

This is much more useful than assigning a price based solely on the fact that the project uses FHIR.

Final Thoughts

The biggest estimation mistake is treating an Epic integration as a single API development task.

In reality, the project can involve several interconnected workstreams:

FHIR implementation + Authentication + Data Mapping + Workflow Engineering + Security + Customer Onboarding + Testing + Maintenance

A narrowly scoped integration may fit within a relatively modest budget. A production implementation with multiple workflows, write-back capabilities, customer-specific requirements, and ongoing support can demand a substantially larger investment.

The right estimate depends on what you're building, which capabilities are available in the target environment, and what it takes to operate the integration reliably.

So instead of asking:

“How much does an Epic integration cost?”

Ask:

“What will it take to build, deploy, validate, and maintain our specific Epic integration in production?”

That question gives your engineering team a much better starting point for estimating both cost and delivery time.

A question for healthcare developers and engineering teams:

For a production Epic integration, which part tends to consume the most engineering effort in your experience: FHIR resource mapping, authentication, customer onboarding, security reviews, or long-term maintenance?

I'd be interested in hearing how your team approaches estimation and what costs are easiest to underestimate.

From Prompt-and-Response to Agentic Workflows: Engineering an AI Content Platform for Telehealth

Om Jariwala — Thu, 08 Oct 2026 07:20:31 +0000

A healthcare company came to us with an internal AI-powered SEO platform.

The prototype already worked.

It could research topics, generate content, perform SEO checks and publish to WordPress.

The problem was scalability.

As the system grew, it became increasingly difficult to maintain. The architecture relied too heavily on a single AI provider, browser-side state and workflows that were not designed for multiple brands.

We needed to turn the prototype into production software without losing the workflow that had already been validated.

1. The original architecture had reached its limits

The initial system was built around a relatively simple interaction:

User Input
    ↓
LLM
    ↓
Response

That works well for experimentation.

It becomes limiting when a workflow needs to remember previous decisions and pass structured context between multiple stages.

The new workflow looked more like:

Topic Discovery
      ↓
Research
      ↓
Content Planning
      ↓
Content Generation
      ↓
SEO Evaluation
      ↓
AEO/GEO Evaluation
      ↓
Human Review
      ↓
Publishing
      ↓
Feedback

Each stage had a specific responsibility.

The system was no longer treating the LLM as one general-purpose assistant.

It was becoming an orchestration layer around multiple specialized tasks.

2. Moving away from a single-model dependency

The original platform depended directly on one LLM provider.

That creates a practical engineering problem.

A model change, pricing change, availability issue or capability change can suddenly become an application-level problem.

We moved the AI layer to OpenRouter so the application could work with multiple models through a common integration.

An image-generation routing layer was also added.

The goal wasn't to use more models for the sake of using more models.

It was to make the application layer less dependent on one provider.

3. Persistent context became part of the workflow

A multi-step content system needs memory of what happened earlier in the workflow.

For example, when evaluating a new article, the system needs to know:

What content already exists?
Has this topic already been covered?
What did the research stage find?
What did previous evaluation stages identify?
What feedback has the human reviewer provided?

Without that context, every stage becomes another isolated AI request.

The architecture therefore shifted toward persistent workflow context.

This allowed different agents to work on different stages while maintaining continuity.

4. AI-generated content still needed human evaluation

Healthcare is not a domain where increasing generation volume is enough.

The platform was designed to support high-volume content production while retaining a human review layer.

SEO specialists and writers could provide natural-language feedback.

That feedback could then become part of the system's context.

The objective was not:

AI → Publish

It was closer to:

AI
 ↓
Evaluation
 ↓
Human Review
 ↓
Feedback
 ↓
Improved Context
 ↓
Next Generation

5. Supporting multiple publishing environments

The platform eventually needed to support both WordPress and Astro-based websites.

WordPress provided an existing CMS workflow.

Astro introduced a different challenge because content specialists needed a CMS-style interface even though the underlying sites were using a more developer-oriented architecture.

The solution was to add CMS capabilities to the platform itself while maintaining compatibility with WordPress.

Custom WordPress components were also required for specific generated content such as HTML-based infographics.

6. The result

What started as an internal AI experiment became a multi-tenant platform supporting around 14 brands.

The platform could connect:

Discovery
   ↓
Research
   ↓
AI Agents
   ↓
SEO / AEO / GEO
   ↓
Human Feedback
   ↓
CMS
   ↓
Publishing

The important engineering lesson wasn't “use AI agents.”

It was understanding when a prototype has stopped being a prototype.

Once an AI workflow becomes part of a real healthcare business, reliability, context, model abstraction, human review and scalable architecture become product requirements.

That's where the engineering work really begins.

Designing an EHR Integration Layer for a Telehealth Platform

Om Jariwala — Mon, 05 Oct 2026 11:51:35 +0000

When developers hear “EHR integration,” the first thought is usually an API.

But a production telehealth platform needs more than an API client.

It needs an integration layer that can handle authentication, mapping, retries, errors, synchronization and external-system failures.

A simplified architecture looks like:

Patient App
     |
     v
Telehealth API
     |
     v
Integration Layer
     |
     +------> EHR
     |
     +------> Lab
     |
     +------> Pharmacy

What should the integration layer handle?

1. Authentication

The integration layer should manage the authentication mechanism required by the target system.

Don't spread EHR credentials and integration logic throughout the core application.

Keep the external integration boundary explicit.

2. Data Mapping

Your internal patient model may not match the external EHR representation.

For example:

Telehealth Patient
    |
    +-- firstName
    +-- lastName
    +-- dateOfBirth
    +-- email

may need to map into a FHIR Patient resource or another format supported by the EHR.

The mapping should be explicit and testable.

3. Patient Identity

This is one of the hardest parts.

The same patient can have different identifiers across systems.

You need a reliable strategy for:

Existing patient lookup
Patient creation
Identifier mapping
Duplicate prevention
Reconciliation

4. Retry and Idempotency

Consider this:

Telehealth Backend
      |
      | Create Encounter
      v
     EHR
      |
      X Timeout

Did the EHR reject the request?

Or did it process the request but the response never reach your application?

Retrying blindly could create a duplicate.

This is where idempotency and transaction tracking matter.

5. Failure Handling

External healthcare systems can fail.

Your integration layer should have a defined strategy for:

Timeouts
Rate limits
Authentication failures
Validation failures
Temporary outages
Partial failures

Queues can help decouple patient-facing workflows from slower external operations where the workflow allows it.

Read vs Write

A basic integration might only retrieve:

EHR → Telehealth

A mature workflow may require:

EHR → Telehealth
Telehealth → EHR

For example:

Patient
   |
   v
Telehealth consultation
   |
   v
Clinical documentation
   |
   v
Integration Layer
   |
   v
EHR

The second direction is often where integration requirements become more complicated.

Test the workflow, not just the endpoint

A successful API response isn't enough.

Test:

Existing patients
New patients
Duplicate patients
Failed requests
Retry scenarios
Missing data
EHR downtime
Duplicate submissions
Write-back failures

An EHR integration is production-ready when the surrounding workflow has predictable behavior, including failure scenarios.

Final thought

The integration layer is not just plumbing between two APIs.

It is a boundary between two systems with different data models, identifiers, failure modes and workflows.

Design that boundary carefully, and future EHR integrations become much easier to manage.

Why Traditional Webhooks Break Under RPM Load

Om Jariwala — Fri, 02 Oct 2026 05:32:03 +0000

A webhook works fine when your system is small.

But when you start handling FHIR data, RPM devices, patient observations, alerts, and hundreds of events, the simple:

Device → Webhook → API → Database

model can become a problem.

The issue isn't the webhook itself.

It's making the webhook responsible for everything.

RPM Device
    ↓
Webhook
    ↓
Validate
    ↓
Transform to FHIR
    ↓
Save Data
    ↓
Run Clinical Rules
    ↓
Send Alert

Now imagine hundreds of devices doing this at the same time.

One slow dependency can hold up the entire request.

A better approach

Use the webhook for ingestion and move the heavy work into an event-driven pipeline.

RPM Device
    ↓
API / Webhook
    ↓
Message Queue
    ↓
Workers
    ↓
FHIR Processing
    ↓
Clinical Rules
    ↓
FHIR Server / Database
    ↓
Notifications

The queue gives your system somewhere to hold events when traffic spikes or a downstream service is temporarily unavailable.

It also makes retries much easier.

Don't forget duplicate events

Distributed systems can deliver the same event more than once.

So your pipeline should be idempotent.

Receive Event
      ↓
Check Event ID
      ↓
Already Processed?
   ↙          ↘
 Yes           No
 ↓             ↓
Ignore       Process

The goal is simple:

Processing an event twice should not create incorrect clinical data.

What about FHIR?

An RPM reading might become a FHIR Observation:

{
  "resourceType": "Observation",
  "status": "final",
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "8480-6",
      "display": "Systolic blood pressure"
    }]
  },
  "valueQuantity": {
    "value": 142,
    "unit": "mmHg"
  }
}

But creating the FHIR resource is only one part.

You still need to handle:

Patient and device identity
Duplicate events
Out-of-order events
Retries
Validation
Clinical rules
Auditability

The real question

Don't ask only:

“Does my webhook work?”

Ask:

“What happens when 10x the events arrive, the FHIR server goes down, or the same event arrives twice?”

That's where architecture starts to matter.

A webhook should tell your system:

“Something happened.”

It shouldn't necessarily be responsible for everything that happens next.

For RPM and FHIR systems, separating ingestion from processing gives you a much stronger foundation for scaling and reliability.