Security and data handling

Both products run on Amazon Web Services in a United States region, in a separate deployment and database for each customer. Techinquest runs the application and the environment it sits in and applies the updates; your teams use it in a browser.

The application reaches its database through a login that can read and write records but cannot change the database’s structure. Databases are backed up every day, and the backups are encrypted like the database.

Production access is restricted to authorized Techinquest administrators. Employees and contractors sign confidentiality agreements.

In transit

Browsers reach both products over HTTPS, with TLS 1.2 as the minimum version, and plain HTTP requests are redirected to HTTPS. Scheduled file transfers run over SFTP, which encrypts the connection.

At rest

Databases, database backups and stored files are encrypted with AES-256, using keys managed by AWS. Database keys are held in the AWS Key Management Service.

The security pack sets out the configuration behind each of these statements.

Your staff sign in through single sign-on with their existing organization account, handed to your identity provider by a managed AWS sign-in service. Your password rules and multi-factor requirements apply, and a person disabled in your directory can no longer sign in.

Vendor reps get individual accounts in Implant Control, which your administrators create, scope and deactivate. Multi-factor authentication is available for these accounts but not yet required for all of them.

Access is role-based in both products: a role decides the screens and actions, and a user can be limited to particular hospitals.

Implant Control

Vendor reps and vendor managers see only requests for the vendors and hospitals their account is assigned to. Which lines can be added, changed or deleted at each status comes from one permission table, enforced on the server and covered by automated tests.

Rebate Recovery

Six health-system roles, every one of them inside the hospital. Users can be restricted to particular hospitals or suppliers, and that limit is applied on the server. New screens open to administrators first and reach other roles later.

Both products work on files: no interface to build into your ERP or EMR, and no API to open on them.

Implant Control

Surgical case and schedule exports from your EMR arrive on a schedule. Approved requests leave as a requisition file for your ERP, and purchase order numbers come back in a return file.

Rebate Recovery

Contract and purchasing data arrives as CSV or Excel files, uploaded in the browser or delivered for scheduled processing. Each upload is checked before anything loads, and rejected rows are reported back.

Scheduled transfers use SFTP, and your systems connect out to a Techinquest endpoint, so nothing inside your network accepts a connection from us. Implant Control also emails vendor reps about their own requests, such as the purchase order number when a request completes.

Implant Control

Requests, lines, notes, contracts, prices, users and vendors all keep a change history. An audit trail screen shows each insert, update and delete with who made it, when, and the values before and after. Each validation run is stored with the case lines it matched, and a purchase order number keyed by hand carries the same trail as one loaded from a file.

Rebate Recovery

Contract and purchasing records carry who created them and who last changed them, and when. Each data file load is logged with its outcome and the rows it rejected. Each AI exchange is logged with who made it, what was asked, the answer and when.

One thing to plan around: Rebate Recovery recalculates rebate figures from current data rather than keeping a point-in-time history of every figure. An export taken at period close is the snapshot to file.

AI appears only in Rebate Recovery. Implant Control has no AI features.

Model requests go to Amazon Bedrock, the managed AI service inside AWS, using its United States routing. The cross-Region inference documentation explains that this routing processes each request in a Region within that geography. The Bedrock data protection documentation states that model providers do not have access to customer prompts and completions.

Reading a contract

A person uploads a signed supplier agreement and the model proposes a draft contract from it; the agreement goes to the model because reading it is the job. Each value shows whether its wording was found on a cited page, a rate with no quote behind it blocks creation until a person confirms it, and the result is always an inactive draft.

Answering questions

The assistant is read-only: it cannot change a contract, link a payment or dismiss an alert. It answers from the reports the person asking may run and takes every figure from them, not from the model. Supplier and contract names are replaced with stand-ins before a request leaves the system and restored in the answer.

Logging

Each exchange is logged with who made it, what was asked or read, the full answer and when. An assistant answer that contains a figure the system could not trace to a report is flagged in the log.

Alerts, calculations and dashboards are rules and arithmetic. None of them is AI.

This page is a summary. For a formal review we provide:

The security documentation pack

An architecture and data-flow description, encryption detail and our answers to a standard vendor security questionnaire, under NDA. Each answer is marked in place, partly in place or planned.

Answers to your questionnaire

We complete your own questionnaire and walk your reviewers through our controls, with the people who build and run the products.

To report a suspected security issue in either product, email support@tech-inquest.com.