Cad Care RISE Resilience and Inclusive Solutions for Emergencies
Pre-launchCad Care RISE is in development. Public launch is expected in 2028, with air ambulance capability targeted for 2030. Nothing on this site describes a service that is currently operating.
PLATFORM · ARCHITECTURE

Technical architecture

How the platform is built: layered systems, an API-first integration surface, and a deliberate separation between governed data and ledger-anchored proof.

Shape

Four tiers, not nine silos

The nine systems are arranged in four tiers. Intake and sensing gather signal. Understanding turns signal into assessment. Action commits resources against that assessment. Assurance — security, accountability and integration — applies across all three rather than following them.

This matters for procurement as much as engineering: an agency can adopt the platform tier by tier, starting with intake and understanding while continuing to run its existing allocation processes.

IIDAMS platform architectureNine systems arranged in four tiers around a canonical data layer, with external interfaces at the base.INTAKE AND SENSINGData GatheringAid Request PortalPartner & sensor feedsUNDERSTANDINGData IntegrationData AnalysisPredictive AnalyticsACTIONResource ManagementAid ManagementCommunicationASSURANCESecurityAccountabilityIntegrationFHIR R4 · REST APIs · legacy adapters · ledger anchoring
Figure 1 — Four-tier platform architecture
Principle

Data and proof are kept apart

Personal, clinical and household data lives in governed storage subject to residency, retention and access controls. What goes to the distributed ledger is verification material: hashes, custody events, consent transitions and access anchors.

The separation is not a technical convenience. Writing a vulnerable person's circumstances to an immutable shared ledger would create a permanent record that no consent withdrawal could ever undo.

What is never written to the ledger

Names, identifiers, clinical detail, household composition, location history. The ledger proves a record has not been altered; it is not a copy of the record.

Components

Technology stack

Platform technology stack
LayerApproach
Blockchain platformSelected per deployment from Ethereum, Hyperledger Fabric or Corda according to scalability, consensus and governance requirements.
Smart contractsAutomate and enforce consent management, access control and transaction validation.
Decentralised storageIPFS or Storj for large-volume data requiring redundancy and integrity without central dependency.
Ledger interfaceWeb3.js for JavaScript services and Web3.py for Python services.
FrontendReact.js or Angular.js, built for responsive use across desktop, tablet and low-cost field devices.
BackendNode.js, Django or Flask handling application logic, data management and ledger interaction.
DatabasePostgreSQL, MongoDB or CouchDB for non-ledger data, complex query and analytics.
APIs and microservicesService architecture with published interfaces enabling exchange with EHRs, LIS and emergency response systems.
Cloud infrastructureAWS, Azure or GCP, with data residency configured per jurisdiction.
SecurityEncryption, authentication, access control and audit applied at every layer rather than at the perimeter.

Read the interoperability approach

Adoption depends on fitting into estates that agencies already run. That is an architecture question before it is a commercial one.