Cross-Clinic Data Sharing: How to Build Interoperable Health Networks with ClinikAPI

Quick Answer

Building a multi-clinic health network means solving two opposing problems at once: clinics need to share patient data for referrals and care coordination, but each clinic's data must stay isolated for privacy and compliance. ClinikAPI solves this with sub-organizations — each clinic gets its own isolated FHIR data partition with separate API keys, while the parent organization can run cross-clinic queries for network-wide reporting and coordinated care. No custom multi-tenancy code. No data leakage risk. Built into the platform.

---

The Multi-Clinic Data Problem

If you are building a platform that serves multiple clinics — a practice management SaaS, a telehealth network, a community health platform — you face a fundamental architecture challenge.

Clinic A's data must be invisible to Clinic B. A patient at Downtown Clinic should not appear in Suburban Clinic's patient list. A provider at one location should not see another location's financial data. This is not just good practice — it is a HIPAA requirement.

But sometimes clinics need to share data. When Downtown Clinic refers a patient to Suburban Clinic, the receiving clinic needs the patient's history. When the network runs quality reports, it needs aggregate data across all locations. When a patient moves between clinics, their records should follow them.

Building this from scratch means implementing multi-tenant data isolation at the database level, building a permission system for cross-tenant queries, handling data migration between tenants, and ensuring audit logging tracks every cross-clinic access. Most teams estimate 2-4 months of engineering work just for the multi-tenancy layer.

---

How ClinikAPI Sub-Organizations Work

ClinikAPI's sub-organization feature handles multi-tenancy at the platform level. Here is the architecture:

Parent Organization (Your Company)
├── Sub-Org: Downtown Clinic (isolated data partition)
├── Sub-Org: Suburban Clinic (isolated data partition)
├── Sub-Org: Eastside Clinic (isolated data partition)
└── Network-level queries (aggregated, authorized)

Each sub-organization gets:

• Its own isolated FHIR data store
• Separate API keys
• Independent audit logs
• Its own patient records, encounters, and clinical data

The parent organization can:

• Create and manage sub-organizations
• Run authorized cross-clinic queries
• Generate network-wide reports
• Facilitate patient referrals between clinics

---

Building a Multi-Clinic Platform: Step by Step

Step 1: Create Sub-Organizations for Each Clinic

When a new clinic joins your network, create a sub-organization:

import { Clinik } from '@clinikapi/sdk';

const clinik = new Clinik(process.env.CLINIKAPI_SECRET_KEY!);

// Each clinic gets its own isolated environment
// (Sub-org creation is done via the developer portal or admin API)

Each sub-organization operates independently. Clinic A's API key only accesses Clinic A's data. There is no way for one clinic to accidentally query another clinic's records.

Step 2: Clinics Operate Independently

Each clinic uses the SDK with its own API key. All operations are scoped to that clinic's data:

// Downtown Clinic's backend
const downtownClinik = new Clinik(process.env.DOWNTOWN_API_KEY!);

const { data: patient } = await downtownClinik.patients.create({
  firstName: 'Jane',
  lastName: 'Doe',
  email: '[email protected]',
  gender: 'female',
  birthDate: '1990-03-15',
});

// This patient only exists in Downtown Clinic's data partition
// Suburban Clinic cannot see this patient

Step 3: Handle Patient Referrals

When Downtown Clinic refers a patient to Suburban Clinic, the referral workflow shares only the necessary clinical data:

// Downtown Clinic creates a referral
const referralData = {
  patientId: 'pt_abc123',
  fromClinic: 'downtown',
  toClinic: 'suburban',
  reason: 'Specialist consultation for cardiac evaluation',
  urgency: 'routine',
};

// Your platform facilitates the data transfer
// Pull the patient's relevant records from Downtown
const { data: patientData } = await downtownClinik.patients.read('pt_abc123', {
  include: ['Encounter', 'Observation', 'MedicationRequest'],
});

// Create the patient in Suburban Clinic's partition
const suburbanClinik = new Clinik(process.env.SUBURBAN_API_KEY!);

const { data: referredPatient } = await suburbanClinik.patients.create({
  firstName: patientData.patient.firstName,
  lastName: patientData.patient.lastName,
  email: patientData.patient.email,
  gender: patientData.patient.gender,
  birthDate: patientData.patient.birthDate,
});

// Transfer relevant clinical history
for (const obs of patientData.observations) {
  await suburbanClinik.observations.create({
    patientId: referredPatient.id,
    code: obs.code,
    value: obs.value,
    unit: obs.unit,
  });
}

The patient now exists in both clinics' systems with their relevant history. Each clinic maintains its own copy — no shared database, no data leakage risk.

Step 4: Network-Wide Reporting

The parent organization can aggregate data across all sub-organizations for quality metrics, financial reporting, and operational insights:

// Parent organization queries across all clinics
// (Using parent-level API key with cross-org permissions)

const networkMetrics = {
  totalPatients: 0,
  totalEncounters: 0,
  averageWaitTime: 0,
};

for (const clinic of clinics) {
  const clinikInstance = new Clinik(clinic.apiKey);

  const { data: patients } = await clinikInstance.patients.search({ count: 0 });
  const { data: encounters } = await clinikInstance.encounters.search({ count: 0 });

  networkMetrics.totalPatients += patients.total;
  networkMetrics.totalEncounters += encounters.total;
}

---

Real-World Scenarios

Community Health Centers

A network of 10 community health centers serves different neighborhoods. Each center has its own patient population, but patients sometimes visit multiple locations. ClinikAPI sub-organizations keep each center's data isolated while enabling patient transfers when needed.

Telehealth Networks

A telehealth platform connects patients with providers across multiple states. Each state's practice operates as a sub-organization with its own clinical data. The platform provides network-wide scheduling and provider matching while keeping clinical records isolated per practice.

Specialist Referral Networks

A primary care network refers patients to a group of specialists. Each specialist practice is a sub-organization. When a referral is made, the relevant clinical data is shared with the specialist — not the entire chart, just what is needed for the consultation.

Franchise Healthcare Models

A healthcare franchise (urgent care, dental, physical therapy) has 50+ locations. Each location is a sub-organization with independent operations. Corporate runs network-wide analytics and quality reporting across all locations.

---

Why Not Just Use Database-Level Multi-Tenancy?

You could build multi-tenancy yourself using PostgreSQL row-level security, separate schemas, or separate databases. But here is what you would need to build:

Component	DIY Effort	ClinikAPI
Tenant isolation	2-4 weeks	Built-in
Cross-tenant queries	2-3 weeks	Built-in
Per-tenant API keys	1-2 weeks	Built-in
Per-tenant audit logs	1-2 weeks	Built-in
Tenant provisioning	1-2 weeks	Built-in
FHIR compliance per tenant	4-8 weeks	Built-in
HIPAA compliance per tenant	4-8 weeks	Built-in
Total	15-29 weeks	Included

And that is just the multi-tenancy layer. You still need to build the actual clinical data model, API, and application on top of it.

---

Frequently Asked Questions

How many sub-organizations can I create? Pro plans include 2 sub-organizations. Team plans include 5. Additional sub-organizations are available on custom plans. Each sub-organization is billed separately for usage.

Can a patient exist in multiple sub-organizations? Yes. When a patient is referred between clinics, they get a separate record in each sub-organization. This is by design — each clinic maintains its own clinical relationship with the patient.

Is cross-clinic data sharing HIPAA-compliant? Yes, when done with proper authorization. Patient referrals and care coordination are permitted uses under HIPAA. ClinikAPI's audit logging tracks every cross-clinic data access for compliance.

Can sub-organizations have different configurations? Each sub-organization operates independently with its own API keys, data, and audit logs. They share the parent organization's plan and billing.

How does this compare to running separate ClinikAPI accounts? Sub-organizations are managed under one parent account, making it easier to provision new clinics, run cross-clinic queries, and manage billing centrally. Separate accounts would require manual coordination.

---

Related Reading

• From Idea to MVP: Ship 10x Faster
• Workflow Automations with Event Flow
• HIPAA Compliance for Developers
• ClinikAPI Pricing