The design history
Every input, output, review and verification for this design, each version as it was approved, and who approved it.
Device makers keep design, production and complaint records for years. Healthcare software must show who saw a patient's data and to whom it went. Tabellix keeps both on one verifiable record.
A quality audit follows the device. A privacy review follows the person the record is about.
Every input, output, review and verification for this design, each version as it was approved, and who approved it.
From the complaint to the investigation, the CAPA and the revised procedure, with nothing missing in between.
Every view and download of records about a person, by whom and when, including emergency access.
For a patient or a recipient: which records left the organization, which versions, and when.
Why someone opened a record outside their normal access, for how long, and who reviewed it afterward.
The approved version of each specification and quality agreement, and what each supplier received.
Design inputs, outputs and reviews are controlled documents with major and minor versions. Typed links pin each item to the version it refers to, and deactivating a link keeps its history.
A complaint is a case record that binds its members in order: the investigation, the CAPA and the revised procedure. Holds, retention and access flow from the case to every member.
Views and downloads are logged before any content is served. Reads of the personal data held about a person are logged whatever access logging mode the deployment sets.
For a recipient or an item: every version released, through which disclosure, with digests. Each disclosure is a sealed, signed bundle that verifies offline.
Emergency access needs a fresh sign-in and a justification, is time-limited, raises an alert, logs every access with the session, and is reviewed through a built-in record and workflow.
Specifications and quality agreements reach suppliers through expiring, watermarked shares, with an agreement before content and a report of what each one fetched.
The same record layer serves the design team, the complaint unit and the release-of-information desk. Each type is configuration.
| Record | Kind | What it holds |
|---|---|---|
| Design input specification DI-0108 | document | Versioned, reviewed and approved with signatures; linked to the outputs and verifications that answer it. |
| Design review | event record | Attendees, outcome and the document versions reviewed, signed with the meaning "reviewed". |
| Sterilization cycle | event record | Cycle, load, parameters and result sent by the controller through the API; a source reference already captured is not stored twice. |
| Complaint CMP-0311 | case record | Intake, investigation, reportability decision and closure as lifecycle steps; the device history and the CAPA as members. |
| Emergency access review | case record | Opened for each break-glass session: the justification, the records opened and the reviewer's signed conclusion. |
| Release of information request | case record | The request and the records released as a sealed disclosure, with the accounting entry for the patient. |
Product controls map to these regulations and standards and provide evidence for your own validation and audits.
No. It is the record layer underneath them. The QMS, the EHR or the complaint system keeps its own screens and workflows, and keeps its documents, records, signatures, retention and audit trail in Tabellix.
Every file is encrypted with its own key and checked on every read. Personal data about each person the records concern sits under that person's own key. Users who may not see a record cannot tell that it exists.
As long as each record type requires, including permanent retention, above a minimum the deployment enforces. When rules overlap the longest period wins, a legal hold blocks disposition, and records administrators approve each disposal.
An agent can gather the device history and draft the complaint summary, under the person's own permissions. High-risk actions wait for the person to confirm out of band with a fresh sign-in, and under the regulated preset only named people approve and sign.
Run it on Kubernetes in your cloud or your customer's, with sign-in through your OIDC provider and people provisioned over SCIM. Your product calls one contract over gRPC or REST, and your product name appears on every customer-visible surface Tabellix provides.
Tell us what you build and who audits it. We'll show you how Tabellix fits into your product and how it answers your auditors' most common questions.