Federation Schema

Purpose: Federated deployment support for on-premise installations syncing to central cloud Tenant Scoped: No (facility-based access control) RLS Enabled: No Location: Central Cloud only

Overview

The federation schema manages:

Registry of on-premise facility installations
Master Patient Index for cross-facility identity
Inbound sync tracking from on-premise facilities
Aggregated clinical data for patient portal
Feature configuration per deployment mode
Cloud-proxied appointment booking

This schema exists only on the Central Cloud, not on on-premise installations.

How Federated Deployment Works

The Two Deployment Modes

Kulcare operates in two deployment modes from a single codebase:

+------------------------------------------------------------------+
|                     DEPLOYMENT ARCHITECTURE                       |
+------------------------------------------------------------------+
|                                                                   |
|   CLOUD SAAS                          ON-PREMISE                  |
|   ==========                          ==========                  |
|                                                                   |
|   +------------------------+          +------------------------+  |
|   | Full Multi-Tenant      |          | Single-Organization    |  |
|   | Platform               |          | Installation           |  |
|   +------------------------+          +------------------------+  |
|   | - All schemas          |          | - Core schemas only    |  |
|   | - RLS enabled          |          | - No RLS               |  |
|   | - Growth/Connect       |          | - No Growth/Connect    |  |
|   | - Federation receiver  |          | - Sync sender          |  |
|   +------------------------+          +------------------------+  |
|            ^                                    |                 |
|            |                                    |                 |
|            +------------------------------------+                 |
|                   Outbound Sync (continuous)                      |
|                   + Appointment bookings (inbound)                |
|                                                                   |
+------------------------------------------------------------------+

On-Premise Schema Relationship

The on-premise database schema is a strict subset of the cloud schema:

Schema	Cloud SaaS	On-Premise	Notes
reference	Full	Full	Same lookup tables
identity	Full + tenant_id	Simplified (no tenant_id)	Single organization
clinical	Full + tenant_id	Simplified (no tenant_id)	Core clinical functionality
billing	Full	Basic	Payment gateway cloud-only
growth	Full	Not included	Cloud-only marketing
connect	Full	Not included	Cloud-only networking
enterprise	Full	Not included	Cloud-only employer benefits
integration	Full	Full	ABDM and webhooks
audit	Full	Full	Compliance logging
federation	Full (12 tables)	Not included	Cloud receives sync
sync	Not included	4 tables	On-premise sends sync

Code Reuse Strategy

Both deployments use the same Rails application codebase with environment-based configuration:

Same Codebase, Different Configuration
======================================

Cloud:                              On-Premise:
  DEPLOYMENT_MODE=cloud               DEPLOYMENT_MODE=on_premise
  MULTI_TENANT=true                   SYNC_ENABLED=true
  FEDERATION=enabled                  ORGANIZATION_ID=<uuid>

Result:                             Result:
  - Load all parts                    - Load core parts only
  - Enable RLS policies               - Skip RLS policies
  - tenant_id on all tables           - No tenant_id columns
  - Federation receiver active        - Sync sender active

Why On-Premise is a Subset

1. Multi-Tenancy Removal

On-premise installations serve a single organization (possibly with multiple facilities), so tenant isolation is unnecessary:

tenant_id columns removed from all tables
Row-Level Security (RLS) policies not created
Simpler queries without tenant filtering

2. Cloud-Only Features

Certain features only make sense in a cloud context:

Feature	Why Cloud-Only
Growth (campaigns, leads)	Marketing requires cloud analytics
Connect (professional network)	Cross-organization by nature
Enterprise (employer benefits)	B2B relationships span organizations
Federation receiver	On-premise sends, cloud receives

3. Sync Layer Inversion

The sync direction is inverted between deployments:

Deployment	Sync Role	Tables
Cloud	Receiver	federation.* (12 tables)
On-Premise	Sender	sync.* (4 tables)

On-Premise Sync Tables

On-premise installations have a dedicated sync schema (not part of cloud):

+------------------------------------------------------------------+
|  SYNC SCHEMA (On-Premise Only)                                    |
+------------------------------------------------------------------+
|                                                                   |
|  +------------------------+    +------------------------+         |
|  | sync_configuration     |    | outbound_sync_queue    |         |
|  +------------------------+    +------------------------+         |
|  | cloud_endpoint_url     |    | resource_type          |         |
|  | api_key (encrypted)    |    | resource_id            |         |
|  | api_secret (encrypted) |    | operation_type         |         |
|  | sync_frequency_minutes |    | payload                |         |
|  | last_sync_at           |    | sync_status            |         |
|  | sync_enabled           |    | retry_count            |         |
|  +------------------------+    +------------------------+         |
|                                                                   |
|  +------------------------+    +------------------------+         |
|  | inbound_appointment_   |    | local_feature_flags    |         |
|  | queue                  |    +------------------------+         |
|  +------------------------+    | feature_key            |         |
|  | cloud_booking_id       |    | is_enabled             |         |
|  | slot_id                |    | override_reason        |         |
|  | patient_data           |    | effective_from         |         |
|  | status                 |    | effective_until        |         |
|  +------------------------+    +------------------------+         |
|                                                                   |
+------------------------------------------------------------------+

Data Flow Between Deployments

ON-PREMISE                                CENTRAL CLOUD
==========                                =============

[clinical.patients]                       [federation.master_patient_index]
[clinical.encounters]     --SYNC-->       [federation.federated_clinical_data]
[clinical.prescriptions]                  [federation.sync_data_provenance]
                                          [federation.patient_identity_links]

[sync.outbound_sync_queue]  --POST-->     [federation.inbound_sync_records]

                           <--PUSH--      [federation.appointment_bookings]
[sync.inbound_appointment_queue]          (cloud-proxied online booking)

Source Code Protection

On-premise deployments protect Kulcare intellectual property:

Ruby source files encrypted with RubyEncoder (.rbe extension)
Decryption keys hardware-locked to licensed servers
Configuration files (database.yml, .env) remain editable
Database migrations readable for schema transparency

Entities

Facility Registry

Entity: FederatedFacility

Purpose: Registry of all on-premise installations syncing to central cloud

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
facility_code	String	Yes	Unique facility identifier
facility_name	String	Yes	Display name
facility_type	Enum	Yes	hospital, clinic, diagnostic_center, pharmacy
deployment_mode	Enum	Yes	on_premise, cloud, hybrid
organization_name	String	No	Parent organization
country_code	String	Yes	ISO country code (IN, US, AE)
state	String	No	State/province
city	String	No	City
timezone	String	Yes	Facility timezone (e.g., Asia/Kolkata)
sync_enabled	Boolean	Yes	Whether sync is active
sync_frequency_minutes	Integer	No	Expected sync interval (default: 15)
last_sync_at	Timestamp	No	Last successful sync
last_heartbeat_at	Timestamp	No	Last connectivity check
sync_status	Enum	Yes	active, degraded, offline, suspended
registration_date	Date	Yes	When facility registered
contract_expiry_date	Date	No	License expiry
data_retention_days	Integer	No	How long to retain synced data
settings	JSONB	No	Facility-specific configuration
created_at	Timestamp	Yes	Record creation
updated_at	Timestamp	Yes	Last update

Sync Status Values:

Status	Description
`active`	Syncing normally within expected frequency
`degraded`	Syncing but with delays or partial failures
`offline`	No sync received beyond threshold (e.g., 24 hours)
`suspended`	Administratively suspended

Settings Structure:

{
  "multi_facility": true,
  "facility_count": 3,
  "max_patients_sync": 10000,
  "sync_priorities": ["patients", "encounters", "prescriptions"],
  "contact_email": "admin@hospital.com",
  "contact_phone": "+919876543210"
}

Indexes:

Unique: facility_code
Index: sync_status
Index: country_code

Entity: FacilitySyncCredentials

Purpose: Secure credentials for facility-to-cloud authentication

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
federated_facility_id	UUID	Yes	Facility reference
api_key_hash	String	Yes	Hashed API key (bcrypt)
api_secret_hash	String	Yes	Hashed API secret (bcrypt)
public_key	Text	No	RSA public key for signed payloads
issued_at	Timestamp	Yes	Credential issuance date
expires_at	Timestamp	No	Credential expiry
last_used_at	Timestamp	No	Last successful auth
is_active	Boolean	Yes	Active status
revoked_at	Timestamp	No	When revoked
revoked_reason	String	No	Revocation reason
created_at	Timestamp	Yes	Record creation

Relationships:

Belongs to: FederatedFacility

Security Notes:

API keys stored as bcrypt hashes
Plain text keys only shown once at creation
RSA public key for payload signature verification
Automatic revocation on expiry

Patient Identity

Entity: MasterPatientIndex

Purpose: Global patient identity aggregation across all facilities

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier (MPI ID)
first_name	String	No	First name (normalized)
last_name	String	No	Last name (normalized)
date_of_birth	Date	No	Date of birth
gender	Enum	No	male, female, other, unknown
phone_hash	String	No	SHA-256 hashed phone number
email_hash	String	No	SHA-256 hashed email
abha_id	String	No	India ABHA identifier
national_id_hash	String	No	Hashed Aadhaar/SSN
identity_confidence	Decimal	No	Overall match confidence (0-1)
primary_facility_id	UUID	No	Primary care facility
facility_count	Integer	No	Number of facilities visited
first_seen_at	Timestamp	No	First record date
last_activity_at	Timestamp	No	Most recent activity
user_account_id	UUID	No	Linked Kulcare user account
is_active	Boolean	Yes	Active record
created_at	Timestamp	Yes	MPI creation
updated_at	Timestamp	Yes	Last update

Indexes:

Unique: abha_id (when not null)
Index: phone_hash
Index: email_hash
Index: (first_name, last_name, date_of_birth)
Index: user_account_id

Privacy Notes:

PHI stored in hashed form for matching
Full demographics come from FederatedClinicalData
User account linking enables patient portal access

Entity: PatientIdentityLink

Purpose: Links facility-local patient records to MPI

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
master_patient_id	UUID	Yes	MPI reference
federated_facility_id	UUID	Yes	Facility reference
facility_patient_id	String	Yes	Patient ID at facility
facility_mrn	String	No	MRN at facility
match_method	Enum	Yes	exact, fuzzy, manual, abha
match_confidence	Decimal	No	Confidence score (0-1)
verified	Boolean	No	Manually verified link
verified_by	UUID	No	Verifying user
verified_at	Timestamp	No	Verification timestamp
is_active	Boolean	Yes	Active link
created_at	Timestamp	Yes	Link creation
updated_at	Timestamp	Yes	Last update

Match Method Values:

Method	Description	Auto-Verified
`exact`	Deterministic match (phone + DOB + name)	Yes
`fuzzy`	Probabilistic match (needs verification)	No
`manual`	Human-verified match	Yes
`abha`	Matched via India ABHA ID	Yes

Unique Constraint: (federated_facility_id, facility_patient_id)

Relationships:

Belongs to: MasterPatientIndex
Belongs to: FederatedFacility

Sync Tracking

Entity: InboundSyncRecord

Purpose: Track all incoming sync operations from on-premise facilities

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
federated_facility_id	UUID	Yes	Source facility
sync_batch_id	String	Yes	Batch identifier from source
operation_type	Enum	Yes	create, update, delete
resource_type	String	Yes	Entity type (patient, encounter, etc.)
facility_resource_id	String	Yes	Resource ID at facility
cloud_resource_id	UUID	No	Mapped ID in cloud (after processing)
payload	JSONB	Yes	Full sync payload
payload_hash	String	No	SHA-256 hash for deduplication
facility_timestamp	Timestamp	Yes	When created at facility
received_at	Timestamp	Yes	When received by cloud
processed_at	Timestamp	No	When processed
sync_status	Enum	Yes	received, processing, synced, conflict, failed
conflict_type	Enum	No	identity_mismatch, data_conflict, validation_error
conflict_data	JSONB	No	Conflict details
error_message	Text	No	Error details
retry_count	Integer	No	Processing attempts
created_at	Timestamp	Yes	Record creation

Sync Status Values:

Status	Description
`received`	Payload received, queued for processing
`processing`	Currently being processed
`synced`	Successfully merged into cloud data
`conflict`	Conflict detected, needs resolution
`failed`	Processing failed after retries

Conflict Type Values:

Type	Description
`identity_mismatch`	Patient identity cannot be matched
`data_conflict`	Data conflicts with existing cloud data
`validation_error`	Data fails validation rules

Indexes:

Index: (federated_facility_id, sync_batch_id)
Index: sync_status
Index: received_at

Relationships:

Belongs to: FederatedFacility

Entity: SyncConflictResolution

Purpose: Track conflict resolution decisions

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
inbound_sync_record_id	UUID	Yes	Sync record reference
conflict_type	Enum	Yes	identity_mismatch, data_conflict, version_conflict
source_data	JSONB	No	Data from on-premise
cloud_data	JSONB	No	Existing cloud data
resolution_strategy	Enum	Yes	source_wins, cloud_wins, merged, manual
resolved_data	JSONB	No	Final resolved data
resolved_by	UUID	No	Resolving user
resolved_at	Timestamp	No	Resolution timestamp
auto_resolved	Boolean	No	Resolved automatically
resolution_notes	Text	No	Human notes
created_at	Timestamp	Yes	Record creation

Resolution Strategy Values:

Strategy	Description
`source_wins`	On-premise data takes precedence
`cloud_wins`	Cloud data takes precedence
`merged`	Data merged from both sources
`manual`	Manually resolved by admin

Relationships:

Belongs to: InboundSyncRecord

Clinical Data Aggregation

Entity: FederatedClinicalData

Purpose: Aggregated clinical data from all facilities for patient portal

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
master_patient_id	UUID	Yes	MPI reference
federated_facility_id	UUID	Yes	Source facility
data_type	Enum	Yes	encounter, prescription, diagnosis, vitals, lab_result, imaging, procedure, document
facility_resource_id	String	Yes	Original ID at facility
data_date	Date	Yes	Clinical event date
data	JSONB	Yes	Structured clinical data
metadata	JSONB	No	Additional metadata
practitioner_name	String	No	Treating practitioner
practitioner_specialty	String	No	Specialty
facility_name	String	No	Facility display name
is_current	Boolean	No	Current status (for ongoing conditions)
synced_at	Timestamp	Yes	When synced to cloud
created_at	Timestamp	Yes	Record creation

Data Type Values:

Type	Description	FHIR Equivalent
`encounter`	Visit/consultation records	Encounter
`prescription`	Medication orders	MedicationRequest
`diagnosis`	Conditions/diagnoses	Condition
`vitals`	Vital signs	Observation
`lab_result`	Laboratory results	DiagnosticReport
`imaging`	Imaging studies	ImagingStudy
`procedure`	Procedures performed	Procedure
`document`	Clinical documents	DocumentReference

Data Structure Examples:

Encounter:

{
  "encounter_type": "consultation",
  "encounter_date": "2025-12-29",
  "chief_complaint": "Fever, cough for 3 days",
  "notes": "Patient presents with...",
  "diagnoses": [
    { "code": "J06.9", "display": "Acute upper respiratory infection" }
  ]
}

Prescription:

{
  "medications": [
    {
      "drug_name": "Paracetamol 500mg",
      "dosage": "1 tablet",
      "frequency": "TID",
      "duration_days": 5
    }
  ],
  "prescribed_by": "Dr. Smith"
}

Vitals:

{
  "blood_pressure": { "systolic": 120, "diastolic": 80 },
  "pulse": 72,
  "temperature": 98.6,
  "spo2": 98,
  "weight_kg": 70,
  "height_cm": 175
}

Indexes:

Index: (master_patient_id, data_type, data_date)
Index: (federated_facility_id, facility_resource_id)
Index: synced_at

Relationships:

Belongs to: MasterPatientIndex
Belongs to: FederatedFacility

Entity: SyncDataProvenance

Purpose: Complete audit trail for data provenance

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
federated_clinical_data_id	UUID	Yes	Clinical data reference
federated_facility_id	UUID	Yes	Origin facility
facility_resource_type	String	Yes	Original table/type
facility_resource_id	String	Yes	Original ID
original_created_at	Timestamp	Yes	When created at facility
original_created_by	String	No	Creator at facility
original_updated_at	Timestamp	No	Last update at facility
sync_version	Integer	Yes	Sync version number
synced_at	Timestamp	Yes	When synced to cloud
inbound_sync_record_id	UUID	No	Sync record reference
created_at	Timestamp	Yes	Record creation

Relationships:

Belongs to: FederatedClinicalData
Belongs to: FederatedFacility
Optionally references: InboundSyncRecord

Feature Configuration

Entity: FeatureConfiguration

Purpose: Control feature availability per deployment mode

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
feature_key	String	Yes	Feature identifier (snake_case)
feature_name	String	Yes	Display name
feature_category	Enum	Yes	core, growth, connect, billing, integration, ai
description	Text	No	Feature description
default_cloud_enabled	Boolean	Yes	Default for cloud deployments
default_onpremise_enabled	Boolean	Yes	Default for on-premise
requires_cloud_proxy	Boolean	No	Needs cloud services when on-premise
cloud_proxy_endpoint	String	No	Proxy endpoint for on-premise
created_at	Timestamp	Yes	Record creation
updated_at	Timestamp	Yes	Last update

Feature Category Values:

Category	Description
`core`	Core CMS functionality
`growth`	Marketing/growth features
`connect`	Professional networking
`billing`	Payment processing
`integration`	External integrations
`ai`	AI-powered features

Example Features:

feature_key	cloud	on_premise	proxy
`patient_queue`	true	true	false
`prescriptions`	true	true	false
`online_booking`	true	true	true
`patient_portal`	true	true	true
`sms_notifications`	true	false	true
`ai_scribe`	true	false	true
`analytics_dashboard`	true	false	true
`payment_gateway`	true	false	false
`growth_campaigns`	true	false	false

Unique Constraint: feature_key

Entity: FacilityFeatureOverride

Purpose: Facility-specific feature overrides

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
federated_facility_id	UUID	Yes	Facility reference
feature_key	String	Yes	Feature reference
is_enabled	Boolean	Yes	Override value
override_reason	String	No	Reason for override
effective_from	Date	No	Override start date
effective_until	Date	No	Override end date
created_by	UUID	No	Admin user
created_at	Timestamp	Yes	Record creation
updated_at	Timestamp	Yes	Last update

Unique Constraint: (federated_facility_id, feature_key)

Relationships:

Belongs to: FederatedFacility
References: FeatureConfiguration (via feature_key)

Appointment Booking

Entity: AppointmentSlots

Purpose: Available appointment slots synced from on-premise facilities

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
federated_facility_id	UUID	Yes	Source facility
facility_slot_id	String	Yes	Slot ID at facility
practitioner_name	String	Yes	Practitioner name
practitioner_specialty	String	No	Specialty
slot_date	Date	Yes	Appointment date
start_time	Time	Yes	Start time
end_time	Time	Yes	End time
duration_minutes	Integer	No	Slot duration
slot_type	Enum	No	consultation, follow_up, procedure
is_available	Boolean	Yes	Currently available
booked_at	Timestamp	No	When booked
synced_at	Timestamp	Yes	Last sync
created_at	Timestamp	Yes	Record creation
updated_at	Timestamp	Yes	Last update

Unique Constraint: (federated_facility_id, facility_slot_id)

Indexes:

Index: (federated_facility_id, slot_date, is_available)
Index: practitioner_name

Relationships:

Belongs to: FederatedFacility

Entity: AppointmentBookings

Purpose: Bookings made via patient portal (pending on-premise confirmation)

Attributes:

Attribute	Type	Required	Description
id	UUID	Yes	Primary identifier
appointment_slot_id	UUID	Yes	Slot reference
federated_facility_id	UUID	Yes	Target facility
master_patient_id	UUID	Yes	Patient (MPI)
user_account_id	UUID	No	Booking user account
booking_status	Enum	Yes	pending, confirmed, rejected, cancelled
rejection_reason	String	No	If rejected
patient_name	String	Yes	Patient name
patient_phone	String	Yes	Contact phone
patient_email	String	No	Contact email
notes	Text	No	Patient notes
booked_at	Timestamp	Yes	Booking timestamp
confirmed_at	Timestamp	No	Confirmation timestamp
cancelled_at	Timestamp	No	Cancellation timestamp
pushed_to_facility_at	Timestamp	No	When sent to on-premise
facility_response_at	Timestamp	No	When facility responded
created_at	Timestamp	Yes	Record creation
updated_at	Timestamp	Yes	Last update

Booking Status Values:

Status	Description
`pending`	Awaiting on-premise confirmation
`confirmed`	Confirmed by on-premise
`rejected`	Rejected (slot unavailable)
`cancelled`	Cancelled by patient

Relationships:

Belongs to: AppointmentSlots
Belongs to: FederatedFacility
Belongs to: MasterPatientIndex

Schema Diagram

+-------------------------------------------------------------------------+
|  FEDERATION SCHEMA                                                       |
+-------------------------------------------------------------------------+
|                                                                         |
|  FACILITY REGISTRY                                                       |
|  +---------------------+    +------------------------+                   |
|  | federated_          |--->| facility_sync_         |                   |
|  | facilities          |    | credentials            |                   |
|  +---------------------+    +------------------------+                   |
|           |                                                              |
|           |                                                              |
|  PATIENT IDENTITY                                                        |
|  +---------------------+    +------------------------+                   |
|  | master_patient_     |<---| patient_identity_      |                   |
|  | index               |    | links                  |                   |
|  +---------------------+    +------------------------+                   |
|           |                          |                                   |
|           |                          |                                   |
|  CLINICAL DATA                       |                                   |
|  +---------------------+    +------------------------+                   |
|  | federated_          |--->| sync_data_             |                   |
|  | clinical_data       |    | provenance             |                   |
|  +---------------------+    +------------------------+                   |
|           ^                          ^                                   |
|           |                          |                                   |
|  SYNC TRACKING                       |                                   |
|  +---------------------+    +------------------------+                   |
|  | inbound_sync_       |--->| sync_conflict_         |                   |
|  | records             |    | resolutions            |                   |
|  +---------------------+    +------------------------+                   |
|                                                                         |
|  FEATURE CONFIGURATION                                                   |
|  +---------------------+    +------------------------+                   |
|  | feature_            |--->| facility_feature_      |                   |
|  | configurations      |    | overrides              |                   |
|  +---------------------+    +------------------------+                   |
|                                                                         |
|  APPOINTMENT BOOKING                                                     |
|  +---------------------+    +------------------------+                   |
|  | appointment_        |--->| appointment_           |                   |
|  | slots               |    | bookings               |                   |
|  +---------------------+    +------------------------+                   |
|                                                                         |
+-------------------------------------------------------------------------+

Entity Summary

Entity	Purpose	Records Expected
FederatedFacility	On-premise registry	Hundreds
FacilitySyncCredentials	Sync auth	1-2 per facility
MasterPatientIndex	Global patient ID	Millions
PatientIdentityLink	Facility-MPI links	Millions
InboundSyncRecord	Sync tracking	Millions (pruned)
SyncConflictResolution	Conflict audit	Thousands
FederatedClinicalData	Clinical data	Tens of millions
SyncDataProvenance	Data provenance	Tens of millions
FeatureConfiguration	Feature matrix	~50 features
FacilityFeatureOverride	Overrides	Hundreds
AppointmentSlots	Available slots	Millions
AppointmentBookings	Portal bookings	Millions

Total Tables: 12

Retention Policies

Table	Retention	Rationale
federated_facilities	Permanent	Facility registry
facility_sync_credentials	Until revoked + 1 year	Security audit
master_patient_index	Permanent	Patient identity
patient_identity_links	Permanent	Matching history
inbound_sync_records	90 days	Operational
sync_conflict_resolutions	2 years	Audit
federated_clinical_data	Per facility contract	Patient data
sync_data_provenance	Same as clinical data	Audit
feature_configurations	Permanent	Configuration
facility_feature_overrides	Permanent	Configuration
appointment_slots	30 days past date	Operational
appointment_bookings	2 years	Audit

Federated Deployment - Architecture overview
Offline Mode - Client-side offline sync
Identity Schema - Core identity entities
Clinical Schema - Clinical data model

Federation Schema

OverviewCopy Anchor Link

How Federated Deployment WorksCopy Anchor Link

The Two Deployment ModesCopy Anchor Link

On-Premise Schema RelationshipCopy Anchor Link

Code Reuse StrategyCopy Anchor Link

Why On-Premise is a SubsetCopy Anchor Link

On-Premise Sync TablesCopy Anchor Link

Data Flow Between DeploymentsCopy Anchor Link

Source Code ProtectionCopy Anchor Link

EntitiesCopy Anchor Link

Facility RegistryCopy Anchor Link

Entity: FederatedFacilityCopy Anchor Link

Entity: FacilitySyncCredentialsCopy Anchor Link

Patient IdentityCopy Anchor Link

Entity: MasterPatientIndexCopy Anchor Link

Entity: PatientIdentityLinkCopy Anchor Link

Sync TrackingCopy Anchor Link

Entity: InboundSyncRecordCopy Anchor Link

Entity: SyncConflictResolutionCopy Anchor Link

Clinical Data AggregationCopy Anchor Link

Entity: FederatedClinicalDataCopy Anchor Link

Entity: SyncDataProvenanceCopy Anchor Link

Feature ConfigurationCopy Anchor Link

Entity: FeatureConfigurationCopy Anchor Link

Entity: FacilityFeatureOverrideCopy Anchor Link

Appointment BookingCopy Anchor Link

Entity: AppointmentSlotsCopy Anchor Link

Entity: AppointmentBookingsCopy Anchor Link

Schema DiagramCopy Anchor Link

Entity SummaryCopy Anchor Link

Retention PoliciesCopy Anchor Link

Related DocumentationCopy Anchor Link

On this page

Overview

How Federated Deployment Works

The Two Deployment Modes

On-Premise Schema Relationship

Code Reuse Strategy

Why On-Premise is a Subset

On-Premise Sync Tables

Data Flow Between Deployments

Source Code Protection

Entities

Facility Registry

Entity: FederatedFacility

Entity: FacilitySyncCredentials

Patient Identity

Entity: MasterPatientIndex

Entity: PatientIdentityLink

Sync Tracking

Entity: InboundSyncRecord

Entity: SyncConflictResolution

Clinical Data Aggregation

Entity: FederatedClinicalData

Entity: SyncDataProvenance

Feature Configuration

Entity: FeatureConfiguration

Entity: FacilityFeatureOverride

Appointment Booking

Entity: AppointmentSlots

Entity: AppointmentBookings

Schema Diagram

Entity Summary

Retention Policies

Related Documentation