Clinaraall care, connected.
Clinara Data Store + Clinara ID
An encrypted object store and a trusted identity system, with separate controls for who you are, what you may access and where information can be read.
Clinara’s security architecture starts before information reaches a server. It protects the content, the keys that unlock it and the clinical meaning around it—while keeping everyday storage, sharing and recovery practical.
Discuss your data architectureClinara Data Store
The application works with records, collections and files. The storage layer handles encrypted objects and opaque identifiers.
A patient record is more than its values. Field names, filenames, relationships, indexes and the manifest that organises a collection carry sensitive meaning. The architecture encrypts these alongside the content, leaving the store with random locators.
Each meaningful object has its own content key. Authenticated encryption protects its contents and detects modification. A recipient’s key envelope protects the small content key separately, so sharing does not require making another readable copy on the server.
Immutable object versions preserve the distinction between an original and a later revision. Encrypted manifests describe which records, images and attachments belong together, so an application can assemble a consistent view of a visit or collection.
Managing capacity, billing, retention or delivery does not confer permission to read a record. Storage capabilities govern which encrypted objects can be retrieved; a separate authority controls access to their keys.
Group the images, notes or files into meaningful objects and a manifest.
Encrypt the objects and manifest. Wrap the content keys for approved recipients.
Keep ciphertext, encrypted key envelopes and random locators.
Content and usable keys stay separate. The storage service is not the authority that unlocks a record.
Clinara ID
Prove who is making a request, show what they are approving, and keep authentication separate from permission to read clinical content.
An enrolled device holds the user’s authentication credentials. Clinara ID displays the requesting service and obtains approval, creating a trusted identity context for the application.
The application evaluates the person, patient or record, assigned role, purpose and session. Belonging to an organisation—or successfully signing in—does not automatically grant access to its patient records.
Verify identity, enrolled device and explicit approval.
Check the record scope, purpose, relationship and expiry.
Wrap only the approved object keys for this short-lived session.
Retrieve ciphertext from Data Store and decrypt inside the permitted boundary.
Clinara ID authenticates. The application authorises. The customer-controlled key broker releases scoped keys. Data Store delivers encrypted content.
A Clinara ID credential proves identity; it is not a master key to clinical information. The ID service and the storage service are outside the content-decryption boundary.
Access is tied to an individual session and a defined scope. Key release follows the current permission state, including expiry and revocation, rather than relying on a permanent shared key for an entire team.
Sharing, continuity & recovery
Separate content, recipient permissions and recovery controls so each can change without handing the infrastructure a universal key.
Each recipient opens only their approved objects. The key broker wraps keys; Data Store never needs a readable record to deliver it.
New permissions can create new recipient envelopes. Revocation stops future grants and session access; information already read or deliberately exported remains subject to the recipient’s own controls.
Identity recovery, replacing a device and restoring clinical records are different operations. Encrypted recovery packages and independent recovery copies are governed by the patient or organisation’s recovery authorities, with no Clinara-operated universal recovery key in the architecture.
Service health, delivery receipts, capacity and failure codes support operations without placing clinical content in routine logs. The infrastructure still needs bounded operational information such as object sizes, timing and commercial account details; those are kept distinct from the encrypted clinical meaning.
Records are read on authorised endpoints or inside a specifically controlled customer workload. A dedicated server alone does not create that boundary: runtime administration and key release must also remain under the customer’s control.
Data Store is a standalone foundation for patient applications, diagnostic devices and services that handle sensitive records. Its SDK presents familiar records, collections, files, versions and shares. Applications retain their own clinical logic and declared content authority while using a common protected storage model.
Clinara’s own applications use the same separation of identity, storage and key authority. Clinara Cloud belongs to the application layer above this foundation.
Beside You.
Customer spotlight
Allie is a Clinara Data Store and Clinara ID customer. These provide the data and identity foundation for its private, personal approach to women’s everyday health and wellbeing.
A place to understand your cycle, notice changes, learn and keep the parts of your life that matter to you together.
Allie combines period and health tracking with a private journal, daily planning and educational content. Record symptoms and experiences, look back over your history and prepare the information you want to take to a care appointment.
Keep cycle history, symptoms, sleep and wellbeing observations in context. Reflect on what changes over time instead of relying on memory at your next consultation.
Use a private journal, reminders and daily plans to connect practical routines with how you feel. Explore information about cycles, wellbeing and the changes you notice.
Personal records stay encrypted and local to the app. Prepare selected entries for a care conversation and review what you choose to share.