Clinical data doesn't stay in one place. It moves between apps, services, and sometimes networks that you don't directly control. If trust only exists at the transport layer—TLS, VPNs, etc.—it disappears once the connection closes.
COSE stands for CBOR Object Signing and Encryption. It's a lightweight standard for signing and encrypting structured data—effectively the binary cousin of JOSE (the JSON-based system behind JWTs).
And in distributed healthcare systems, COSE lets you attach cryptographic proof to the data itself, not the channel it travels through.
Why It Matters
In traditional architectures, trust is built into the connection. Your browser trusts the server because TLS says the certificate is valid. Your API client trusts the endpoint because it's behind a firewall and authenticated session.
But what happens when:
- A FHIR resource gets cached on a mobile device for offline use?
- A consent lease is synchronised across three different FHIR Cube nodes?
- An observation travels from edge device to clinical system, then onward to a research archive?
At each stage, the original connection is gone. If trust was only in the transport, you've lost it.
COSE makes trust portable. Each object carries its own signature and, if required, encryption envelope. Verification can happen anywhere along the path—no dependency on the original service.
When It's Used
We use COSE whenever data might leave its original context:
- Between FHIR Cube nodes — each resource is signed by the issuing node, so downstream systems can verify provenance without calling back to the source.
- Through FHIR Plane — when resources traverse mesh networks or air-gapped segments, COSE ensures integrity survives the journey.
- Mobile device synchronisation — a clinician working offline can receive signed updates that remain verifiable even when disconnected.
Each payload carries its own proof of origin. That's essential in a distributed environment where "edge", "mobile", and "cloud" all coexist.
Where It Helps
COSE makes provenance and authenticity portable.
A record, consent lease, or observation remains verifiable long after it's been transmitted, cached, or replicated. This matters for:
- Clinical safety — you can prove that an observation came from a trusted device and hasn't been tampered with.
- Regulatory compliance — audit trails remain intact across distributed storage.
- Patient trust — consent decisions travel with the data, cryptographically bound to the record.
In practice, this means a GP receiving a remote monitoring alert can verify it came from the patient's registered device—even if the alert passed through three intermediary systems.
How It Works in Practice
COSE is designed for constrained environments. It uses:
- CBOR encoding — compact binary format, significantly smaller than JSON
- Ed25519 signatures — fast, secure public-key cryptography
- Detached or embedded signatures — flexible for different use cases
Here's a simplified flow:
- A FHIR resource is created on a FHIR Cube node
- The resource is encoded as CBOR
- The node signs it with its private key using Ed25519
- The signature is attached as a COSE envelope
- The resource is transmitted (via FHIR Plane, direct sync, or other means)
- Any recipient can verify the signature using the node's public key
No round-trip to the original source. No reliance on active network connections. Just cryptographic proof that travels with the data.
Example: Consent Leases in Practice
A patient grants consent for their blood pressure readings to be shared with their GP practice for 90 days. This consent is encoded as a FHIR Consent resource, signed with COSE by the patient's HealthFoundry node.
When the GP's system receives a blood pressure observation three weeks later, it can verify:
- The observation came from the patient's authenticated device
- The consent is still valid (timestamp within 90-day window)
- Neither has been modified since signing
All of this happens locally, without calling back to the patient's node. The trust is in the object, not the connection.
COSE vs. JOSE: When to Use Which
You might be familiar with JOSE (JSON Object Signing and Encryption)—it's what powers JWTs and many API authentication systems.
So why COSE?
| Aspect | JOSE (JSON) | COSE (CBOR) |
|---|---|---|
| Format | Text-based (JSON) | Binary (CBOR) |
| Size | Larger | Smaller (30-50% reduction typical) |
| Best for | Web APIs, human-readable systems | Constrained environments, IoT, mobile |
| Use in healthcare | OAuth tokens, session management | Device data, offline sync, edge computing |
In short: JOSE for APIs, COSE for everything that moves.
Alignment with FHIR Security Extensions
FHIR already has robust security mechanisms:
- Provenance resources track who did what and when
- Consent resources encode patient permissions
- AuditEvent resources log access patterns
COSE complements these by adding cryptographic verification. A Provenance resource says "this was created by Node A at timestamp T". A COSE signature proves it.
This makes distributed healthcare systems both auditable and tamper-evident—a quiet but essential distinction when you're designing for national scale.
Separating Data Trust from Network Trust
The traditional security model says: "Protect the pipe, and the data will be safe."
The distributed model says: "Protect the data, and let it travel freely."
COSE enables the second model. It doesn't replace TLS or VPNs—it complements them. The network still provides confidentiality and availability. But COSE provides integrity and authenticity that survive beyond the connection.
In short: COSE lets us separate data trust from network trust.
Why This Matters at National Scale
When you're building healthcare infrastructure that spans:
- GP practices with intermittent connectivity
- Community health workers on mobile devices
- Hospital systems with strict network boundaries
- Research platforms aggregating anonymised data
...you can't assume a single trusted network. You can't assume continuous connectivity. You can't assume centralised authentication servers are always reachable.
What you can assume is that cryptographic signatures, properly implemented, remain verifiable anywhere.
That's what COSE gives you. It's not flashy. It's not a buzzword. But it's the quiet layer that keeps trust intact when everything else is in motion.
Looking Ahead
As healthcare becomes more distributed—more local nodes, more edge computing, more patient-controlled data—the need for portable trust will only grow.
COSE is already an IETF standard (RFC 8152). It's well-aligned with FHIR's own security extensions. And it's efficient enough to run on constrained devices.
We're using it in production. It works. And it lets us build systems where trust doesn't depend on always being connected.
That's a quiet but important foundation for the future of digital health.
