Common questions from rheumatologists and practice administrators
TENSOR Med is an AI-supported clinical decision-support system for rheumatology. Every recommendation cites its source and every reasoning step is recorded. If you'd rather see the system in action than read, run a curated patient journey first — it takes seconds and uses no real patient data.
Things you'll want to know in your first hour with the system.
Each patient runs through a panel of independent AI analyst agents — one focused on guidelines, one on published trials, one on safety, and one on the overall clinical picture. Their outputs go through a consensus check that flags disagreement before anything reaches you.
You always see the reasoning, not just the answer. Every recommendation lists the citations the agents used and the chain of inference that produced it.
The literature base is a curated corpus of guidelines, landmark trials, and drug profiles for axSpA, RA, PsA, gout, SLE, and GCA/PMR. Every citation links back to the exact paragraph the analyst referenced — paraphrased quotes are not allowed.
Sources include ASAS / EULAR axSpA guidelines, EULAR RA guidelines, GRAPPA PsA guidelines, ACR / EULAR criteria sets, pivotal trials per drug class (TNFi, IL-17i, JAKi, IL-6Ri), and label-aligned monitoring profiles.
Yes. Every recommendation carries a confidence indicator (high / moderate / low) and a short rationale for why. Low-confidence recommendations are worded more cautiously and ask you to confirm before acting.
The same is true for parsed data from uploaded documents — fields the parser is unsure about are flagged for your review before they land in the patient record.
Every recommendation has three buttons in the report: Accept, Modify, and Not doing this. Modifying or rejecting prompts you for a reason category — preference, contraindication, cost, patient choice, or clinical disagreement.
The reason becomes a clinical constraint on that patient. The next regeneration respects it: the system won't keep re-suggesting something you've already declined.
Safety alerts can be acknowledged or dismissed. Acknowledged alerts stay visible but don't block. Dismissed alerts are recorded with a reason — the system notes that you've already considered and ruled out the concern, and won't re-fire the same alert on the next regeneration unless something material changes (new lab, new comorbidity, new drug).
The "physician notes" field on each encounter is parsed alongside the structured data. Type a free-text note there and it'll feed into the next regeneration's reasoning. For longer-lived context (preferences, family history that won't change), use the "patient context" field on the patient page — that travels with every report version.
From the Patients tab, click + Add patient in the top right. Enter name, date of birth, sex, and a working diagnosis. The system checks for duplicates against your existing patients before creating the record. If a likely match exists you'll be shown the candidate and asked to either link to it or — if it's genuinely a different person — override.
Once created, fill in clinical detail by hand or upload existing documents (clinic letter, discharge summary, lab printout) and the parser will populate the encounter.
Yes — that's the primary on-boarding path for an existing caseload. From the patient page, drop in:
The parser produces a structured preview before anything is saved. You review, correct anything wrong, and commit. Nothing lands in the patient record without your click.
Document parsing handles English, Turkish (including older hospital PDFs that aren't Unicode-encoded), and Spanish. The AI reads and reasons in any of the three. The on-screen interface is in English — Turkish localisation is on the roadmap.
The system reasons from clinical evidence, not from your local formulary by default. If you reject a recommendation citing "not on formulary," that becomes a constraint on the patient and the system will avoid that drug for them in future regenerations. To set a formulary at the practice level so it applies to every patient, ask your admin — practice-level formulary rules are on the roadmap.
Yes. The reproductive-status field is parsed from documents and from your direct entry, and the AI consciously filters drug recommendations against pregnancy compatibility. For actively planning patients there's a curated journey ("pregnancy planning") under the Demo tab if you want to see how the system handles a planning-stage patient end to end.
Yes — the system handles multi-disease patients (e.g., axSpA with comorbid IBD, or RA with PsA overlap). Disease-specific scores and recommendations show side by side, and the analysts reason about drug choices that benefit or contradict each diagnosis.
Every report version has a Download PDF button. You can attach it to a clinic note, share it with another physician, or print it for the patient.
After any new clinical input — a new lab, a new encounter, a new symptom log. The system also auto-regenerates on data ingestion (debounced about thirty seconds after the last change to avoid wasting LLM calls on bursts of uploads). You can force a fresh regeneration manually from the report page.
The clinician. The system is decision-support, not autonomous prescribing. Every recommendation requires your accept-or-reject before it influences treatment. The audit trail records who accepted what, when, and why — your judgement is the final one and the system is transparent about that.
The Living Report is organised into four layers, each answering a different clinical question:
Today: every patient in your practice. When the practice admin enables per-clinician scoping, you'll see only the patients you're explicitly assigned to. Admins, owners, and read-only observers retain full visibility for oversight and audit.
The registry never carries duplicate records — the system blocks creation of a patient who closely matches an existing one. If you genuinely need two records for two different people with similar identifiers, you can override after reviewing the flagged match.
Patient journeys are curated, multi-phase clinical storylines we built across the six diseases the system covers. Each one walks you through diagnosis → treatment → response, exactly the way a real patient would unfold over months.
Journeys live under the Demo tab and never mix with your real patient registry.
The dashboard is deterministic — same inputs, same output. The AI synthesis is run once and then cached: the first pass on a journey runs the LLM, every subsequent pass replays the cached output for free in under a second. When the underlying prompts or knowledge base change, the cache invalidates and the next run is fresh.
From practice settings, issue an invitation to the clinician's email and pick their role (admin, clinician, read-only observer, or legacy member). They'll receive a sign-up link, complete authentication, and accept the invite. Their membership in your practice is created on acceptance.
Owner role isn't invitable — promote a user to owner after they've joined. This prevents an admin from creating parallel owners.
When per-clinician scoping is enabled, every patient must have at least one active "primary clinician" assignment for that clinician to see them. From the patient page, the assignments panel lets you add a clinician with one of three roles:
Assignments are soft-deleted when revoked, so the audit trail of who looked after whom and when stays intact across staffing changes.
Every read or write to patient data is logged with: timestamp, user, role at the time of the action, why they had permission to access (assignment, admin override, observer, owner, legacy), the action itself (read, modify, export, etc.), and the resource. The Audit tab in the nav is a read-only viewer over the same log for your practice.
Audit entries are append-only and not editable by any role, including owner.
Yes — filter the audit log by user. Every read, write, and export is recorded with enough detail that a compliance officer can answer "did Dr. X access patient Y between dates A and B" in a single query.
Indefinitely by default. We can configure a retention window per practice on request — typical clinical retention is seven years post-last-encounter, aligned with most jurisdictions' clinical-record retention rules. Retention policies are part of pilot onboarding, not a hidden default.
The short version your DPO will want to hear:
Three paths are available:
All exports are tagged with the requesting user, the practice, and the timestamp. Patient exports honour the same access gates as patient reads — clinicians can only export their assigned patients when scoping is enabled.
Use the patient erasure action from the patient page. It redacts identifying fields (name, MRN, contact info, DOB coarsened to year), clears free-text notes, deletes uploaded document blobs, and writes an audit row recording the erasure itself.
Optionally hard-deletes labs, treatments, and symptoms when you toggle "delete clinical data too." GDPR Art. 17, KVKK Art. 7, and HIPAA right of access all route through this same flow.
Remove them from the practice via practice settings. Their assignments to patients are soft-deleted (so the audit trail of who looked after whom stays intact), and their session fails at the next API call once their practice membership is gone. For an immediate session-level kick in an incident scenario, contact TENSOR support.
We provide a full data export — FHIR bundles per patient, audit log, uploaded documents — within fourteen days of contract termination. After you confirm the export is complete, your practice's data is permanently deleted from our infrastructure within thirty days unless you ask us to retain it.
We follow the GDPR / KVKK seventy-two-hour notification requirements. If a confirmed breach affects your practice's data, you'll be notified directly with the scope, the affected patients (anonymously identified), and the remediation plan. We have not had a breach.
We're in pilot phase, so no formal SLA today. The system has been running uninterrupted through the demo period. For production use we move to a contracted SLA — typically 99.5% monthly uptime — before signing the first paying customer.
Yes — the demo environment is the sandbox. Until your practice is provisioned in production mode, all activity stays in the demo space and creates no real patient records. When you're ready, we either migrate selected demo journeys into your production practice or start production cleanly.
For a single rheumatology practice with one or two clinicians: half a day for setup and invitations, plus a few hours for the practice to upload existing patient documents. For a multi-department hospital: one to two weeks depending on integration with their existing EHR.
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 like "Eğitim Aldı" arrive intact rather than corrupted into "E?itim Ald?". The decoder tries Unicode first, then Windows-1254 (Turkish), then a final fallback — that covers both modern and older HBYS systems. Same approach for Spanish accents and other accented European scripts.
Below 70% confidence, the document is automatically routed to manual review — it never lands in the patient record without you explicitly approving the extraction. A second-pass AI verifier also flags any specific fields where the extraction looks suspect, so you don't have to proof-read every line.
On every patient creation, the system runs a fuzzy match against existing patients in your practice — name, date of birth, sex, diagnosis. If a likely match exists you're shown the candidate and asked to either link to the existing record or, if it's genuinely a different person, override and create separately.
Match confidence is reported as one of three labels: strong match (block by default), possible match (warn and surface for review), and no match (allow). The block can be overridden by the clinician after they've reviewed the flagged candidate.
Common SI / US convention conflicts (CRP mg/L vs mg/dL, glucose mmol/L vs mg/dL, creatinine μmol/L vs mg/dL) are auto-converted to canonical SI units on import. The original unit is preserved on the row in case you need to audit the conversion.
Unknown units are flagged for review rather than silently coerced. You'll see a "unit needs review" badge on the affected lab row.
DD/MM/YYYY (the EU and Turkish convention) is tried first, then MM/DD/YYYY (US). Unambiguous dates (e.g., 25/12/2024) work either way. For ambiguous dates (10/03/2024) the EU interpretation wins by default — correct for Istanbul, Madrid, and London. US-deployed practices can request a configuration flip.
How TENSOR Med handles patient data under HIPAA, GDPR, and KVKK.
Patient data is segregated by practice at every layer — database, API, and audit trail. A clinician at one hospital cannot read another hospital's records even if they know a patient identifier; the gate is enforced on every patient-scoped action, not just on the UI.
Every API call is logged. PHI never appears in error messages or external logs — even when an internal parser fails, the response is a generic message with a reference ID, and the actual diagnostic stays in the (PHI-scrubbed) server log.
Before any text reaches the AI, it is run through the de-identifier:
A second scanner verifies no direct identifiers survived before the API call goes out. Calls with surviving identifiers are blocked, not sent.
The technical safeguards (45 CFR 164.312) are in place: role-based access control, append-only audit log, transmission security, encryption at rest. The administrative safeguards (164.308) are deployment-specific — they require organisational policies you put in place, including a Business Associate Agreement with TENSOR Med and our infrastructure providers.
We can sign BAAs with covered-entity practices on request.
GDPR Art. 17 (right to erasure), Art. 20 (right to data portability), and Art. 32 (security of processing) are addressed by the patient erasure flow, the FHIR-bundle export, and the role-aware access gates respectively.
KVKK substantially mirrors GDPR for clinical data — the same flows satisfy KVKK Art. 7 (right to erasure) and Art. 12 (security obligations). Lawful basis under both regimes is treatment by health professionals, with your practice acting as data controller.
Patient data lives in a PostgreSQL instance with row-level security and encryption at rest. Document binaries (uploaded PDFs, images) live in encrypted object storage. Database region is configurable per pilot — discuss your residency requirements before pilot launch and we'll match them.
Owner or admin removes the user from practice membership in practice settings. Their access fails at the next API call once their membership is gone — there is no in-flight session that keeps them in for long. For an immediate session-level kick (rare, used for incidents only), contact TENSOR support.