LifeCare Network — Developer Documentation

Build on a patient-controlled identity, consent, and authorization layer for health data — that stores no health data, ever.

LifeCare.ID lets your application authenticate users with a self-sovereign identity and request machine-readable, cryptographically signed, revocable consent over a person's health data — wherever that data actually lives. A full compromise of LifeCare.ID yields tokens, public keys, and consent metadata, never a single health value.

This documentation is for two kinds of developer:

You are building…	Start here
An application that signs users in and reads consented health data (a coach, a clinic portal, a research tool)	Getting started → Authentication
A data source / connector that holds data and serves it to authorized requesters (a device bridge, a lab feed, a home node)	Data sources & connectors

The status legend (read this first)

LifeCare.ID is shipping incrementally. To keep this documentation honest, every capability is tagged:

✅ Live — implemented today in the service API. You can build against it now. Backed by the published contract in docs/contracts/openapi.json.
🛣️ Roadmap — a planned capability of the future developer portal and network. Documented here so you can design toward it, but not yet available. Don't build against a roadmap feature expecting it to exist.

Where a page mixes both, each section carries its own tag. When in doubt, the contract file is the source of truth for what exists.

The two-sided network

LifeCare.ID is the trust fabric between people, the apps they use, and the places their data lives. It is not a data store, an aggregator, or a proxy.

        ┌─────────────────────────────────────────────────────────┐
        │                    LifeCare.ID                           │
        │   identity (DIDs) · consent (receipts + ledger) ·        │
        │   authorization (UMA-style tokens + revocation)          │
        └───────▲───────────────────▲───────────────────▲─────────┘
                │ sign-in /          │ grant / revoke    │ token
                │ token              │ consent           │ validation
   ┌────────────┴──────┐   ┌─────────┴────────┐   ┌──────┴───────────┐
   │  Relying-party    │   │   The person     │   │  Data source /   │
   │  APP (requester)  │   │  (DID holder)    │   │  connector       │
   │  e.g. ProForta    │   │  device-held key │   │  (resource host) │
   └─────────┬─────────┘   └──────────────────┘   └──────┬───────────┘
             │                                            │
             │   raw data flows DIRECTLY, app ↔ source    │
             └────────────────────────────────────────────┘
                 (LifeCare.ID is never in this path)

The invariant. For any data value d held by a resource holder R and delivered to a requester Q, the transfer R → Q is direct. No LifeCare.ID component is an intermediary, cache, proxy, or co-processor of d. LifeCare.ID participates only in {DID, public key, token, scope, consent receipt, revocation status}. This is an architectural guarantee you can rely on — and a rule your integration must respect (see Security & compliance).

Core roles

Role	Who	What they hold
DID holder (the person)	end user	the private signing key, on their device (never leaves it)
Relying-party app	your app	a `client_id`/`client_secret`, user sessions, access tokens
Data source / connector	a resource host	the actual data + the obligation to honor tokens
Authorization server (AS)	LifeCare.ID	DID authority, consent registry, token issuer, revocation registry
Trust partner	a medical practice (prod) / node operator (MVP)	approves identity recovery / key rotation

See Concepts for the full model.

Documentation map

Foundations - Concepts — DIDs, identity custody, the AS, scopes, consent, the invariant - Bill of rights — why you can't be deplatformed: the structural guarantees (and the honest levers) ✅ - Getting started — a relying-party app, end to end, in minutes (with cURL / JS / Python) - Build a healthspan app, end to end — the sequel: what the node serves once you hold a token (interpreted context, write-back, the Sense/Watch/Reason/Learn/Guard capability map), and the two-system model ✅ / 🛣️ - Sandbox — self-serve a client + a passkey-free test identity; engage with no access request ✅ - Quickstart repos ↗ — clone-and-run reference apps (an app + a data source), zero dependencies

Building an app - Authentication — Sign in with LifeCare.ID — OAuth 2.0 + PKCE ✅ - Onboarding & accounts — design patterns for account creation + onboarding, and the pitfalls ✅ - Your data & the DID — keying your CRM on the DID: the data boundary, durability, revocation/retention, and your responsibilities ✅ - Scopes & consent — the scope vocabulary, purpose binding, receipts, the ledger ✅ - Authorization & tokens — UMA-pattern data-access tokens, introspection, revocation ✅ - Embedding the consent panel — the "Powered by LifeCare.ID" data-rights panel ✅

Building a data source - Data sources & connectors — joining the network as a resource host ✅ / 🛣️

Guides - Recipes — task-oriented how-tos: verify-node badge, embed the panel, become a CGM source, handle revocation ✅

Reference - API reference — the full endpoint catalogue (today's contract) ✅ - Security & compliance — the zero-PHI invariant, your obligations, and verifying a node you integrate with ✅ - Procurement & compliance — a self-serve pack for security reviewers (zero-PHI, BAA, GDPR, audit trail) ✅ - Roadmap — what's live, next, and trigger-gated ✅ · changelog ↗ - Developer terms — the terms you accept to get access ✅ - The developer portal — self-service: sandbox client registration + access gate live ✅; full portal (production registration, keys, governance) 🛣️

Status today

LifeCare.ID's L1–L3 layers (identity, consent, authorization) and the "Sign in with LifeCare.ID" federation handshake are live. App and data-source onboarding is operator-mediated today (your client is provisioned by the network operator) and self-service via the developer portal is on the roadmap — that gap is exactly what the portal page describes. Everything you need to integrate functionally exists now.

The health capabilities your app reads — interpreted context, and (on the roadmap) events, intelligence, and safety — are served by the node, not by LifeCare.ID (which by invariant holds no health data). Build a healthspan app, end to end is the map of that surface and what's live vs roadmap.