Common questions from rheumatologists and practice administrators
TENSOR Med is an AI-supported clinical decision-support tool for rheumatology. Every recommendation cites its source, and every reasoning step is recorded. If you would rather see it work than read about it, run a curated patient journey first. It takes seconds and uses no real patient data.
The things you are most likely to reach for in your first hour with the system.
When you ask for an AI read, four analysts examine the case at once, each from a different angle: treatment response, guideline position, trial evidence, and drug safety. They propose next steps, respond to each other, and a moderator reconciles them into one recommendation.
You always see the reasoning, not just the answer. Every recommendation lists the citations behind it and the steps that led to it, and when the analysts disagree the report says so plainly rather than presenting a split as a certainty.
From an encoded library of guidelines, landmark trials, and drug profiles for the diseases the system covers. Every citation points to a specific source, and you can click it to read the exact passage in the report, or, when the citation is a value from the patient's own record, jump straight to that value. A citation that cannot be resolved is flagged rather than shown as if confirmed.
Sources include the ASAS/EULAR (axSpA), ACR/EULAR (RA), GRAPPA (PsA), EULAR (SLE) and ACR (gout) guidelines, pivotal trials per drug class, and label-aligned monitoring profiles.
Each recommendation has three actions in the report: Accept, Modify, and Not doing this. Modifying or declining asks you to pick a reason: allergy, adverse reaction, patient refusal, a physiological reason such as pregnancy or renal function, your ordering preference, a time-limited hold, insufficient data, or clinical disagreement.
That reason becomes a constraint on the patient, so the next report respects it and does not keep re-suggesting something you have already declined.
You can acknowledge it or dismiss it. An acknowledged alert stays visible but does not block. A dismissed alert is recorded with your reason, and the same alert is not raised again on the next report unless something material changes, such as a new lab, a new drug, or a new comorbidity.
Yes. Each recommendation carries a confidence grade and a short reason for it. When the analysts genuinely split, the grade is lowered rather than inflated, and the recommendation is worded to ask you to confirm before acting.
Because it is checked. After the AI writes its summary, a separate pass compares every score it cites against the recorded value. If the wording had drifted, the number is corrected back to the record before you ever see it, and anything that cannot be safely reconciled (a lab value, a guideline band, a recommendation that conflicts with the data) is flagged for you rather than quietly changed. The figures you read are the figures in the record.
Use the physician-notes field on the encounter. It is read alongside the structured data and feeds the next report. For longer-lived context that should follow the patient (preferences, family history), use the patient-context field on the patient page; it travels with every report version.
On the Patients page, click + Add patient and enter name, date of birth, sex, and a working diagnosis. Before it creates the record, the system checks for a likely duplicate in your practice. If it finds one, it shows you the candidate and asks whether to link to it or, if it is genuinely a different person, create a new record.
After that you can fill in the clinical detail by hand or upload existing documents and let the parser populate the encounter.
Yes, and it is the usual way to bring an existing caseload in. From the patient page you can drop in:
The parser shows a structured preview first. Nothing lands in the record until you review and commit it.
Yes. Reproductive status is read from documents and from what you enter, and drug recommendations are checked against pregnancy and conception plans, including the washout each teratogen needs. There is a pregnancy-planning journey under the Demo tab if you want to see how it handles a planning-stage patient end to end.
Yes. Disease-specific scores and recommendations show side by side, and the analysts reason about drugs that help or conflict across the diagnoses (for example axSpA with coexisting IBD, or an RA and PsA overlap).
It reasons from the clinical evidence, not from your local formulary. If you decline a recommendation on that basis, it becomes a constraint for that patient and the drug is avoided for them in future. There is no practice-wide formulary setting today, so declining per patient is the way to exclude a drug.
Document parsing handles English, Turkish (including older hospital PDFs that are not Unicode-encoded), and Spanish, and the AI reads and reasons in any of the three. The on-screen interface is in English.
The report reflects the whole current record. It refreshes automatically a short time (about thirty seconds) after new data arrives, so a burst of uploads does not trigger a run per file, and you can force a fresh run from the report page at any time.
Yes. Every report version has a Download PDF button, so you can attach it to a clinic note, share it with a colleague, or print it.
You are. It is decision support, not autonomous prescribing: every recommendation needs your accept-or-decline before it affects treatment, and the audit trail records who decided what and when. The judgment stays with the clinician.
Each patient is one report with four levels of depth:
By default, every patient in your practice. If your admin turns on per-clinician scoping, you see only the patients assigned to you, while admins, owners, and read-only observers keep full visibility for oversight.
In an emergency you can still reach an unassigned patient with break-glass access, which asks for a reason and is logged.
They are curated, multi-phase clinical storylines across the diseases the system covers, each walking from diagnosis through treatment to response the way a real patient unfolds over months. Use one to:
Journeys live under the Demo tab and never mix with your real registry.
The dashboard is deterministic, so the same inputs give the same output. The AI read runs once and is then cached, so a repeat replays instantly at no cost. When the underlying prompts or knowledge base change, the cache refreshes and the next run is fresh.
In practice settings, send an invitation to their email and choose their role (admin, clinician, or read-only observer). They receive a sign-up link, sign in, and accept, which creates their membership.
Owner is not invitable; promote an existing member to owner after they join. This stops an admin from creating parallel owners.
When per-clinician scoping is on, a clinician sees a patient only if they have an active assignment to them. From the patient page you add a clinician in one of three roles:
Removing an assignment soft-deletes it, so the record of who looked after whom stays intact across staffing changes.
Every read or write to patient data is logged with the time, the user, their role at the time, why they had access (assignment, admin, observer, owner, or legacy), the action, and the resource. The Audit tab in the nav is a read-only view of the same log for your practice.
Entries are append-only and cannot be edited by anyone, including the owner.
Yes. Filter the log by user. Every read, write, and export is recorded in enough detail to answer whether a given clinician accessed a given patient between two dates.
Indefinitely by default. The retention window is configurable per practice; the default target is seven years after the last encounter, in line with common clinical-record retention. Retention is set during onboarding, not left as a hidden default.
The essentials:
Three ways:
Every export is tagged with the user, the practice, and the time, and honours the same access rules as reads: with scoping on, a clinician can only export their assigned patients.
Use the erasure action on the patient page. It redacts the identifying fields (name, MRN, contact details, and date of birth coarsened to the year), clears free-text notes, deletes uploaded document files, and records the erasure itself in the audit log. You can also choose to hard-delete the clinical data (labs, treatments, symptoms).
This is the same flow behind a GDPR Article 17, KVKK Article 7, or HIPAA erasure request.
Remove them from the practice in settings. Their assignments are soft-deleted so the audit trail stays intact, and their access stops at their next request once their membership is gone.
You get a full export of your data (per-patient FHIR bundles, the audit log, and uploaded documents), and your practice's data is deleted from our systems once you confirm the export is complete. The exact timelines are set in your agreement.
We follow the GDPR and KVKK requirements, including notification within 72 hours of a confirmed breach. If one affected your data, you would be notified directly with the scope and the remediation plan.
We are in pilot, so there is no formal SLA yet; a contracted uptime target is agreed before production use.
The demo environment is the sandbox. Until your practice is provisioned for production, activity stays there and creates no real patient records. When you are ready, we start production cleanly.
It depends on practice size and whether you are importing an existing caseload. For a single practice it is largely self-serve: send the invitations and upload your existing documents. For a larger site with EHR integration, we scope the work with you.
What you can upload, and what to expect from each format.
Whatever the format, the parser produces a structured preview before anything is saved. You review and commit.
Turkish names such as "Eğitim Aldı" come through intact rather than corrupted into "E?itim Ald?". The decoder tries Unicode first, then Windows-1254 (Turkish), then a final fallback, which covers both modern and older hospital systems. The same approach handles Spanish accents and other accented scripts.
Below about 70% confidence the document is routed to manual review and never lands in the record without your approval. A second check also flags the specific fields that look unreliable, so you are not proofreading every line.
On every patient creation, the system fuzzy-matches against your existing patients on name, date of birth, sex, and diagnosis. It reports one of three results:
You can override a block after reviewing the flagged candidate.
Common SI and US conflicts (CRP mg/L vs mg/dL, glucose mmol/L vs mg/dL, creatinine µmol/L vs mg/dL) are converted to canonical units on import, with the original value kept on the row so the conversion can be audited. Unknown units are flagged for review rather than converted silently, and you will see a "unit needs review" badge on the affected row.
Day/month/year (the EU and Turkish convention) is tried first, then month/day/year. Unambiguous dates (for example 25/12/2024) work either way. For a genuinely ambiguous date (10/03/2024) the EU reading is used by default, which is correct for Istanbul, Madrid, and London; a US-format region can have this switched.
How TENSOR Med handles patient data under HIPAA, GDPR, and KVKK.
Patient data is separated by practice at every level: database, API, and audit trail. A clinician at one site cannot read another site's records even with a patient identifier, because the check runs on every patient action, not just in the interface.
Every API call is logged, and identifiers never appear in error messages or external logs. When something fails internally, the response is a generic message with a reference ID, and the detail stays in the (identifier-scrubbed) server log.
The record is de-identified first:
A second check verifies no direct identifier survived. A call that still contains one is blocked, not sent.
The technical safeguards are in place: role-based access, an append-only audit log, transport security, and encryption at rest. The administrative safeguards depend on your organisation's policies, including a Business Associate Agreement, which we can sign with covered-entity practices.
The right to erasure (GDPR Article 17, KVKK Article 7), data portability (Article 20), and security of processing (Article 32) are covered by the erasure flow, the FHIR export, and the access gates respectively. Your practice is the data controller, and the lawful basis under both regimes is treatment by health professionals.
In a PostgreSQL database with row-level security and encryption at rest. Uploaded files (PDFs, images) sit in encrypted object storage. The database region is configurable, so tell us your residency requirements before launch and we will match them.
An owner or admin removes them from practice membership in settings. Their access stops at their next request once their membership is gone, so there is no long-lived session that keeps them in.