Most healthcare software is designed as if the environment were stable: reliable connectivity, consistent digitization, predictable workflows, and a single regulatory model. Anyone who has worked inside real hospitals knows this is rarely the case.
Clinical systems often operate with partial records, uneven infrastructure, mixed paper and digital workflows, and regulatory obligations that vary by region and institution. These conditions are not edge cases. They are the normal operating environment.
The white paper linked below comes out of that reality. It documents a systems architecture for clinical decision support, healthcare operations, and preventive analytics that is explicitly designed for uneven infrastructure, regulatory constraints, and operational pressure.
At the center of the architecture is a simple but underused idea: treating clinical triage as a first-class systems signal rather than a one-time intake step.
This white paper was written in response to a recurring pattern observed across both low-resource and highly digitized health systems: triage data is captured early, then effectively disappears from system behavior. As a result, downstream workflows, safety checks, analytics, and governance mechanisms often operate without structured awareness of patient risk.
Why Triage Matters as a Systems Primitive
In many health IT platforms, triage ends once a patient is placed in a queue. Everything that follows is driven by static workflows, clinician discretion, or downstream systems that no longer “see” patient risk in a structured way.
The approach described in the white paper treats triage more like a control signal than a form field. Once assigned, triage classification continues to shape how the system behaves.
In practice, this means triage influences:
- how workflows branch and escalate
- when decision support activates and when it stays silent
- what safety checks are enforced
- which data is visible to which roles
- what data is eligible for analytics or secondary use
The white paper expands this idea across the full system lifecycle, including encounter flow control, security architecture, offline-first infrastructure, data governance, and preventive analytics. Each layer is described with explicit control boundaries and illustrated with architecture diagrams.
Handled this way, patient risk remains explicit and enforceable across clinical operations, security controls, and planning functions, without automating diagnosis or replacing clinician judgment.
Triage as a Systems Control Layer: Patient inputs feed into the triage control engine, which performs acuity assessment, risk stratification, priority classification, and confidence scoring to generate a persistent control signal.
End-to-End Platform Architecture
The Dalili Health platform employs a layered architecture that separates concerns across interaction, intelligence, clinical services, data management, governance, and infrastructure domains. Each layer has clearly defined responsibilities and exposes controlled interfaces to adjacent layers.
The interaction layer encompasses clinician interfaces, patient intake mechanisms, and ambient capture systems that assist with documentation. The intake and triage layer structures patient data and emits triage control signals. The decision support layer orchestrates safety checks, contextual guidance, and documentation assistance. Clinical and operational data domains store primary records under strict access controls. Governance and compliance layers enforce consent, purpose limitation, and auditability.
This layered design allows the platform to evolve without compromising safety or governance and supports both facility-anchored and cloud-native deployments.
Dalili Health End-to-End Platform Architecture: From user interaction layer through intake and triage, decision support, clinical data domain, governance and compliance, down to infrastructure and security—with external system integrations.
Clinical Encounter Flow and Control Boundaries
Clinical encounters progress through structured stages from registration to documentation. At each stage, triage classification determines the appropriate workflow path and the level of system support provided.
- Low-acuity presentations follow standard workflows with minimal system intervention
- Medium-acuity cases activate contextual decision support, including safety checks and documentation assistance
- High-acuity cases trigger immediate escalation protocols, surfacing critical alerts and prioritizing clinician attention
At all times, clinicians retain full authority to override system behavior. Overrides are explicitly logged, creating a transparent audit trail of clinical decision-making. This ensures accountability while preserving clinical autonomy.
Clinical Encounter Flow: Entry through registration and structured intake, triage assessment branching to standard, enhanced, or escalation pathways, clinical decision support activation, and clinician review with accept, modify, or override options.
Architecture Built for Uneven Infrastructure
The work was motivated by a persistent gap between how digital health systems are designed and how care is actually delivered across regions.
The architecture supports two deployment patterns that share the same logical structure and governance model.
For example, in facility-anchored deployments, a clinic can continue triage, documentation, and clinical workflows entirely offline, with encrypted local storage and queued synchronization when connectivity returns. The same logical architecture, when deployed in cloud-native environments, supports real-time decision support and analytics while enforcing regional data sovereignty and auditability.
Facility-anchored, online-first systems
Designed for environments with intermittent connectivity and partial digitization. Facilities operate autonomously with encrypted local storage and queued synchronization when connectivity becomes available. Paper workflows remain part of the system rather than something the software tries to eliminate.
Cloud-native, regulation-bound systems
Designed for environments with reliable connectivity, mature digital ecosystems, and strict regulatory requirements. These deployments support real-time decision support, analytics, and deep integration while enforcing data sovereignty, auditability, and access control.
Because both patterns share the same architectural assumptions, systems can evolve over time without being redesigned from scratch.
Multi-Region Deployment Topology: Unified governance with regional autonomy. Africa region uses facility nodes with offline support, Europe operates cloud-native with GDPR compliance, Americas runs cloud-native with HIPAA compliance—all connected through shared governance for consistency.
Governance and Security by Design
Rather than layering governance on top of an existing platform, the architecture embeds it directly into system behavior.
Key design choices include:
- explicit separation between clinical data, operational data, analytics outputs, and social-services indicators
- governance gates that enforce consent, purpose limitation, and access control before data is transformed or reused
- lineage and provenance tracking for data used beyond primary clinical care
- role-based and purpose-based access enforced technically, not procedurally
- auditability of system actions, including clinician overrides
This allows regulatory alignment across jurisdictions while preserving clinician autonomy and patient trust.
These controls are enforced programmatically at runtime and cannot be bypassed through configuration or policy alone.
Integrating Social Services Without Exposing Clinical Records
The paper also addresses a common pressure point: how healthcare systems can support preventive planning and social services coordination without exposing protected health information.
The proposed model allows social services to work with aggregated, de-identified indicators derived from healthcare operations. Referrals remain clinician-initiated, and social services do not access clinical records or diagnostic data.
This makes it possible to support elderly care, long-term care coordination, chronic condition management, and vulnerability planning while maintaining strict confidentiality boundaries.
Designing for Real Operating Conditions
The architecture described in the white paper is grounded in environments where clinical systems operate under constraint rather than ideal conditions. Connectivity is uneven, records are incomplete, and paper and digital workflows coexist as part of routine care delivery.
Instead of attempting to eliminate these conditions, the design treats them as operational facts. Safety, governance, and clinician oversight are enforced through system behavior, allowing the same architectural foundation to adapt as infrastructure and regulatory requirements evolve.
Read the Full White Paper
The full paper, Dalili Health: A Triage-Led Clinical Decision Support, Operations, and Preventive Analytics Platform for Resource-Variable Health Systems (PDF), includes detailed architecture diagrams, threat modeling, deployment maturity models, and economic assumptions grounded in peer-reviewed research.
If you work on distributed systems, regulated platforms, health informatics, or infrastructure for high-stakes environments, you may find it useful.
About the Author
Eunice Kamau is a distributed systems architect working on large-scale, mission-critical platforms across healthcare and financial systems, with a focus on automation, reliability, governance, and real-time services under operational and regulatory constraints.
© 2025 Dalili Health. This document is published with permission of the author. All rights reserved.