Architectural Blueprints: How We Built an Isolated Clinical Data Sandbox

When we set out to design MedClino's data architecture, we had one guiding principle: failure in one part of the system must never cascade to other parts. In healthcare software, this is not just an engineering best practice — it is a patient safety imperative.

A billing server going down should never prevent a doctor from accessing a patient's medication history. A licensing verification failure should never lock clinicians out of clinical tools during an emergency. A cloud outage should never mean that a standalone clinic cannot function.

To achieve this, we architected MedClino around three completely isolated database engines, each serving a distinct scope and each capable of operating independently.

Engine 1: The Local Isolated Engine (Single-User Privacy Layer)

The local engine is the foundation of MedClino's desktop application. It is an embedded, file-based database that lives entirely on the user's machine.

Scope: Clinical operations for a single-user environment — patient records, prescriptions, appointments, pharmacy, billing, and reporting.

Key characteristics:

• Zero network dependency for any operation
• AES-256 encryption at the file level
• No external authentication required once the application is authenticated
• No shared tenant space — the database is physically unique to each installation
• Backed by a transactional engine with full ACID compliance

Isolation guarantee: No code running in the cloud workspace engine or the core gateway has any direct access to this engine's data. Data only leaves this engine when the user explicitly syncs or exports.

This means that a security breach at the cloud layer — as catastrophic as that would be — has zero ability to expose data stored in any local engine. The local data is not accessible over any network interface; it exists only on the physical machine.

Engine 2: The Cloud Workspace Engine (Multi-User Collaboration Layer)

The cloud workspace engine powers MedClino's multi-user, multi-department, multi-facility deployments. It runs on MedClino's managed cloud infrastructure and provides the shared database layer for all workstations in a cloud workspace deployment.

Scope: Collaborative clinical operations across multiple users and departments — shared patient records, real-time dashboards, cross-department workflows, centralized reporting, and administrative management.

Key characteristics:

• Multi-tenancy with strict data isolation between facilities
• Row-level security ensuring users only access data within their permission scope
• Real-time event streaming for live dashboard updates without polling
• Horizontal scalability to handle facilities of any size
• Automated daily snapshots with 90-day retention

Isolation guarantee: Each MedClino cloud workspace is a completely separate data context. A query from Facility A cannot, under any circumstances, return data belonging to Facility B — this isolation is enforced at the database query level, not just at the application layer, meaning a bug in the application code cannot accidentally cross tenant boundaries.

Engine 3: The External Core Gateway (Infrastructure and Licensing Layer)

The third engine is the most invisible to end users but equally critical: the external core gateway. This is the engine that powers MedClino's website, licensing verification, subscription management, and inter-system communication APIs.

Scope: License activation, subscription status, user account management, public-facing APIs, and website operations.

Key characteristics:

• Completely separate infrastructure from all clinical databases
• Contains no patient data whatsoever — only license identifiers, account credentials, and billing information
• Rate-limited and monitored for abuse patterns
• Geographically redundant with 99.99% uptime SLA

Isolation guarantee: The core gateway has no query access to any clinical data — not the local engine, not the cloud workspace engine. It can verify that a license is valid and that a subscription is active, but it has no concept of what that licensed installation contains or who its patients are.

Why Isolation Prevents Catastrophic Failures

The power of this three-engine design becomes clearest when you consider failure scenarios:

Scenario 1: Core Gateway Outage

MedClino's licensing server goes offline for planned maintenance. Impact: License renewal and new account creation are temporarily unavailable. Clinical impact: Zero. The local engine continues operating independently. The cloud workspace engine continues serving authenticated users. No clinical workflow is interrupted.

Scenario 2: Cloud Workspace Engine Issues

A specific cloud workspace environment experiences database connection issues. Impact: Users relying on the cloud workspace experience degraded performance. Clinical impact: Any workstation running MedClino desktop in local mode continues functioning normally. Data captured locally queues for sync.

Scenario 3: Local Machine Failure

A workstation running MedClino desktop fails due to hardware issues. Impact: That specific workstation is unavailable. Clinical impact: Other workstations in the facility continue normally. Synced data is already preserved in the cloud workspace. Local data that had not yet synced is recoverable from the local backup if the drive is physically intact.

Scenario 4: Security Breach in One Engine

An attacker gains unauthorized access to the external core gateway database. Impact: Account credentials may be compromised. Clinical impact: Zero patient data is accessible from the core gateway. Clinical data requires separate, independent credentials and is stored in completely separate infrastructure.

The Design Principles Behind the Sandbox

Our three-engine isolation model is grounded in several well-established security engineering principles:

Principle of Least Privilege: Each engine is only granted the permissions it absolutely requires. The core gateway cannot read clinical data because it has no credentials to do so, not because we trust it not to.

Defense in Depth: Even if an attacker circumvents one layer of security, they encounter a completely separate, independent security layer at the next engine. Compromising the outer layer buys them nothing against the inner layer.

Blast Radius Minimization: When things go wrong — and in complex distributed systems, they eventually do — we engineer to ensure the consequences are as narrow as possible. An issue in one engine cannot propagate to another.

Data Gravity: We keep clinical data as close to the clinical environment as possible. The local engine represents the extreme end of this principle: clinical data stays on the clinical machine.

For Healthcare IT Administrators

If you are evaluating MedClino for deployment in a hospital environment, we provide detailed technical documentation on our three-engine architecture, including network topology diagrams, data flow documentation, and security boundary specifications.

We also provide a technical whitepaper on our data safety boundaries and offer architecture review sessions with our engineering team for enterprise and multi-facility deployments.

---

Interested in understanding MedClino's data architecture in depth? Connect with our technical team to download the full architectural whitepaper and discuss deployment options for your facility.