Cardinal Backend

Build Health Apps Fast

Why reinvent the backend when you can ship in weeks?

The AI-Assisted Development Revolution

The era of coding copilots is here

  • Claude Code / Codex / GitHub Copilot let you write application code at unprecedented speed
  • A developer can now prototype a full frontend in days, not months
  • Entire CRUD systems, UI flows, API integrations — generated and refined with AI assistance

The bottleneck has shifted. Writing code is no longer the hard part. Making it compliant, secure, and production-ready is.

The New Problem: Speed vs. Safety

Building fast is easy. Building right is hard.

What AI helps you do fast

  • UI / UX prototyping
  • Business logic
  • API integrations
  • Data transformations
  • Frontend scaffolding

What still takes months

  • Security architecture
  • Penetration testing
  • Compliance certification
  • Encryption infrastructure
  • Data privacy audits

A healthcare app with a security breach doesn't just lose users — it faces lawsuits and regulatory action.

The Real Cost of Building From Scratch

┌─────────────────────────────────────────────────────────────┐
│  TIMELINE: Healthcare Backend From Scratch                  │
│                                                             │
│  Month 1-2    Authentication, RBAC, user management         │
│  Month 2-4    Data model design, API development            │
│  Month 3-5    Encryption implementation & key management    │
│  Month 4-6    FHIR/HL7 interoperability mapping             │
│  Month 5-7    Security audit & penetration testing          │
│  Month 6-9    GDPR/HIPAA compliance certification           │
│  Month 7-10   Performance testing & hardening               │
│  Month 9-12   Bug fixes, edge cases, key recovery           │
│                                                             │
│  ⏱  Total: 9–12 months before you can even start on UX     │
└─────────────────────────────────────────────────────────────┘

What is Cardinal?

A production-ready backend for health data applications

What you get

  • Hosted API at api.icure.cloud
  • End-to-end encrypted data storage
  • Pre-built healthcare data model
  • Multi-language SDKs
  • Real-time event streaming
  • User management & auth

What you skip

  • Months of backend development
  • Cryptographic engineering
  • Compliance certification
  • Security infrastructure
  • Interoperability mapping
  • Penetration testing

Part 1

Security Without the Headache

Compliant, pen-tested, and E2E encrypted out of the box

E2E Encryption — Built In, Not Bolted On

Cardinal encrypts before data leaves the device

   Your App (Client)                      Cardinal (Server)
   ┌─────────────────┐                   ┌─────────────────┐
   │                 │                   │                 │
   │  Patient data   │    Already        │  ████████████   │
   │  "John Doe"     │ ──────────────>   │  ████████████   │
   │  BP: 140/90     │   Encrypted       │  ████████████   │
   │                 │                   │                 │
   │  SDK encrypts   │                   │  Server CANNOT  │
   │  automatically  │                   │  read the data  │
   └─────────────────┘                   └─────────────────┘

Zero-knowledge architecture: Neither Cardinal's team, nor your ops team, nor any attacker who compromises the server can read patient data.

Three-Layer Key Hierarchy

Military-grade encryption without the PhD

┌─────────────────────────────────────────────────────────┐
│  Layer 1: PERSONAL KEYS (RSA)                           │
│  One per user — stored on device only                   │
│  Used to decrypt exchange keys                          │
├─────────────────────────────────────────────────────────┤
│  Layer 2: EXCHANGE KEYS (AES)                           │
│  One per data-sharing relationship                      │
│  Enables secure collaboration between users             │
├─────────────────────────────────────────────────────────┤
│  Layer 3: ENTITY KEYS (AES)                             │
│  One per medical record                                 │
│  Encrypts the actual patient data                       │
└─────────────────────────────────────────────────────────┘

HMAC-SHA256 signatures ensure key authenticity — even a compromised database can't forge access.

Why E2E Encryption Matters

It's not just about checking a box

Without E2E (traditional)

  • Server stores cleartext data
  • Database breach = full data leak
  • You trust every admin, every DBA
  • Compliance = policies & promises
  • Encryption "at rest" still decryptable by the system

With Cardinal E2E

  • Server stores encrypted blobs
  • Database breach = useless data
  • Zero trust required
  • Compliance = architecture
  • Only authorized users with keys can decrypt

GDPR Article 32 & HIPAA Security Rule both recommend encryption. Cardinal makes it the default, not an afterthought.

The SDK Makes Crypto Invisible

Developers never touch keys, ciphers, or delegations directly

// Create a patient — SDK encrypts automatically
const patient = await sdk.patient.createOrModifyPatient(
  new Patient({ firstName: "Jane", lastName: "Doe" })
)

// Create medical data — encrypted before leaving the device
const contact = new DecryptedContact({ descr: "Annual checkup" })
const created = await sdk.contact.createContactWithPatient(patient, contact)

// Share with another doctor — key exchange happens behind the scenes
await sdk.contact.shareWith(otherDoctorId, created)

// Retrieve — SDK decrypts transparently
const retrieved = await sdk.contact.getContact(created.id)
console.log(retrieved.descr)  // "Annual checkup" ← decrypted

Compliance by Architecture

Requirement DIY Approach Cardinal
GDPR data protection Manual implementation + audit E2E encryption by default
HIPAA security rule Policies + encryption layer Zero-knowledge architecture
Pen testing Hire security firm, 4-8 weeks Already done, continuously tested
Access control Build RBAC from scratch Role & entity-based access built in
Audit trail Custom logging pipeline Automatic created/modified/author
Data deletion Hard delete + verification Soft delete with full audit trail
Key management Build or integrate HSM Automatic key lifecycle + recovery

Part 2

A Data Model That Speaks Healthcare

Pre-built, battle-tested, and ready to go

Healthcare Data Model — Ready to Use

No schema design needed — Cardinal models the real world

┌─────────────────────────────────────────────────────────┐
│  PATIENT                                                │
│  ┌───────────────────────────────────────────────────┐  │
│  │  CONTACT (visit / lab result / phone call)        │  │
│  │  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐  │  │
│  │  │  SERVICE    │ │  SERVICE    │ │  SERVICE    │  │  │
│  │  │  Blood      │ │  Diagnosis  │ │  Prescr.    │  │  │
│  │  │  pressure   │ │             │ │             │  │  │
│  │  └─────────────┘ └─────────────┘ └─────────────┘  │  │
│  └───────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────┐  │
│  │  HEALTH ELEMENT (chronic condition, allergy...)   │  │
│  └───────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────┐  │
│  │  DOCUMENT (PDF, imaging, scans — encrypted)       │  │
│  └───────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

Rich Entity Types

Everything you need for a health application

Clinical

  • Patient — demographics & medical history
  • Contact — encounters, consultations, events
  • Service — atomic medical observations
  • HealthElement — chronic conditions, allergies
  • Document — PDFs, imaging, large files

Operational

  • HealthcareParty — doctors, clinics, organizations
  • User — authentication & identity
  • Device — connected medical devices
  • Message / Topic — encrypted messaging
  • Agenda / CalendarItem — scheduling

Medical codification built in: SNOMED-CT, LOINC, ICD-10, ATC — all supported through the Code/CodeStub system.

Content Types — Handle Any Medical Data

The Service entity supports 10+ content types out of the box

Type Field Use Case
Number numberValue Lab results, scores
String stringValue Notes, narratives
Measure measureValue BP, heart rate (with unit, min, max)
Medication medicationValue Prescriptions with full detail
Time Series timeSeries ECG, EEG signals
Document ref documentId Linked PDFs, images
Compound compoundValue Nested service groups
Boolean booleanValue Yes/no assessments
Date fuzzyDateValue Approximate dates (YYYYMMDD)
Binary binaryValue Small binary payloads

Part 3

Interoperability

Speak the language of healthcare systems

FHIR & HL7 Ready

Connect to the existing healthcare ecosystem

FHIR Identifiers

Every entity supports FHIR-compliant identifiers

{
  system: "http://hospital.org/mrn",
  value: "MRN-12345",
  type: { type: "MR" },
  assigner: "St. Mary's Hospital"
}

Out-of-the-box FHIR mapping

Medical Codification

Built-in support for standard vocabularies

  • SNOMED-CT — clinical terms
  • LOINC — lab & clinical observations
  • ICD-10 — diagnostic codes
  • ATC — drug classification

Why it matters: Health apps don't exist in isolation. Hospitals, insurers, labs, and pharmacies all speak FHIR/HL7. Cardinal speaks it natively.

Interoperability: DIY vs. Cardinal

┌──────────────────────────────────────────────────────────┐
│  Building interoperability from scratch                  │
│                                                          │
│  1. Study FHIR R4 spec (600+ pages)                      │
│  2. Map your data model to FHIR resources                │
│  3. Implement identifier system                          │
│  4. Build code system integration (SNOMED, LOINC, ...)   │
│  5. Handle versioning and migrations                     │
│  6. Test against conformance suites                      │
│  7. Maintain as specs evolve                             │
│                                                          │
│  ⏱  3-6 months of specialized work                      │
└──────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│  With Cardinal                                           │
│                                                          │
│  ✓ FHIR identifiers on every entity                      │
│  ✓ Code/CodeStub system maps to any standard             │
│  ✓ Searchable by system + value                          │
│  ✓ Already designed for healthcare workflows             │
│                                                          │
│  ⏱  Ready on day one                                    │
└──────────────────────────────────────────────────────────┘

Part 4

Developer Experience

Five SDKs. Real-time events. Ship fast.

Multi-Platform SDKs

One backend, every platform

Available SDKs

  • Kotlin — Android & JVM
  • TypeScript — Web & Node.js
  • Python — Backend & data science
  • Dart — Flutter mobile
  • Swift — iOS native

What each SDK gives you

  • Transparent E2E encryption
  • Type-safe API wrappers
  • Automatic key management
  • Rich filtering & querying
  • WebSocket event streaming

Same API, every language. Learn it once, use it everywhere. The cryptographic complexity is hidden behind clean, idiomatic interfaces.

Real-Time Event Streaming

React to medical data changes instantly

// Subscribe to new contacts for the current user
const events = await sdk.contact.subscribeToEvents(
  ["CREATE"],
  await sdk.contact.filterContactsBy(/* your filter */)
)

for await (const event of events) {
  // ML analysis, notifications, integration workflows...
  console.log("New contact created:", event.contact.id)
}

Use Cases

  • Real-time dashboards
  • ML-based analysis triggers
  • Automated notifications
  • Integration pipelines

Built-in Features

  • WebSocket-based delivery
  • Encryption-aware filtering
  • Entity-level subscriptions
  • Create / Update / Delete events

Secure Data Sharing Made Simple

Complex access control, simple API

   Dr. Alice creates a record
        │
        ├── Shares with Dr. Bob (READ_WRITE)
        │     └── Dr. Bob can read AND modify
        │
        ├── Shares with Patient Jane (READ)
        │     └── Jane sees her own data
        │     └── Server CANNOT see Jane's identity (anonymous delegation)
        │
        └── Shares with Lab (READ)
              └── Lab reads results only
  • Explicit data owners: HCPs — ID visible in metadata (public professionals)
  • Anonymous data owners: Patients — ID hidden, access via hashed keys
  • Hierarchical access: Doctor > Department > Hospital cascading permissions

User Management — Complete Solution

Authentication, registration, and roles out of the box

For Patients

  • Self-registration with email verification
  • CAPTCHA integration
  • Remember-me sessions
  • 2FA support

For Healthcare Professionals

  • Invitation-based onboarding
  • Role-based access control
  • Organization hierarchies
  • Multi-device key sync

Key recovery is built in: password-protected backups, file export/import, notary system for sharing recovery keys with trusted parties.

Part 5

The Argument for Cardinal

AI writes code. Cardinal makes it safe.

The Modern Stack: AI + Cardinal

┌──────────────────────────────────────────────────────────┐
│                    YOUR APPLICATION                      │
│                                                          │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Frontend / UX  ←── Built fast with AI copilots    │  │
│  │  Business Logic ←── Claude Code / Copilot / Codex  │  │
│  └────────────────────────┬───────────────────────────┘  │
│                           │ Cardinal SDK                 │
│  ┌────────────────────────▼───────────────────────────┐  │
│  │  Cardinal Backend                                  │  │
│  │  ✓ E2E Encryption     ✓ FHIR/HL7 Ready             │  │
│  │  ✓ GDPR/HIPAA         ✓ Pen-Tested                 │  │
│  │  ✓ Data Model         ✓ Real-Time Events           │  │
│  │  ✓ Key Management     ✓ User Auth                  │  │
│  └────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────┘

Time to Market: The Real Comparison

Phase From Scratch With Cardinal
Backend infrastructure 2-3 months 0 (hosted)
Data model design 1-2 months 0 (pre-built)
Encryption & key mgmt 2-4 months 0 (automatic)
User auth & management 1-2 months 0 (built in)
FHIR/HL7 interop 2-4 months 0 (native)
Security audit & pen test 1-2 months 0 (done)
Compliance certification 2-3 months 0 (covered)
Your app's unique value Month 12+ Week 1

Ship in weeks, not years. Use AI copilots for your frontend and business logic. Let Cardinal handle the hard, regulated backend.

What You Focus On vs. What Cardinal Handles

You build (with AI)

  • User experience & design
  • Business-specific workflows
  • Custom analytics & reports
  • Patient engagement features
  • Integration with your systems
  • What makes your app unique

Cardinal provides

  • Encrypted data storage
  • Secure data sharing
  • Access control & permissions
  • Medical codification
  • Real-time event streaming
  • Compliance infrastructure

Focus on what differentiates your product. Don't rebuild what's already been built, tested, and certified.

Who Uses Cardinal?

Cardinal powers applications across the health spectrum

  • EHR systems — full electronic health records
  • Telemedicine — encrypted video + data
  • Patient portals — self-service health data
  • Clinical research — anonymized data sharing
  • IoT health — smartwatch & device integration
  • Care coordination — multi-provider collaboration
  • Mental health — highly sensitive data protection
  • Pharmacy — prescription management
  • Insurance — claims & health data processing
  • Public health — population health monitoring

Recap

Why Cardinal Backend?

  1. AI copilots changed the game — you can build UIs and business logic faster than ever, but backends still need compliance, security, and pen-testing

  2. E2E encryption by design — zero-knowledge architecture means even a full server breach exposes nothing. Compliance is built into the architecture, not bolted on with policies

  3. Healthcare data model included — Patient, Contact, Service, HealthElement, Document and more — all pre-built with 10+ content types

  4. Interoperability out of the box — FHIR identifiers, SNOMED-CT, LOINC, ICD-10 on every entity. Speak the language of hospitals and labs from day one

  5. Ship in weeks, not months — Five SDKs, real-time events, user management, key recovery. Focus on what makes your app unique

Start Building Today

docs.icure.com — Documentation
cardinalsdk.com — Overview

Kotlin TypeScript Python Dart Swift