Tasy support: how to open a useful ticket without exposing patient data
"Tasy is not working" is not a ticket. What to write so support can reproduce the problem, how to show the error without exposing the patient and how to close the ticket without creating another problem.
Every hospital that runs Tasy opens tickets: to internal IT, to the infrastructure provider, to the vendor's support. A well-written support ticket gets solved in hours; a poorly written one spends days going back and forth with questions. And a ticket with a screenshot full of patient data is a privacy incident.
What every ticket needs
- What you were trying to do: the function, the screen, the step.
- What you expected to happen.
- What happened: the exact error message, the odd behavior.
- When: date and time, and whether it always happens or only sometimes.
- Where: facility, department, computer or workstation, browser when relevant.
- Who: the user who had the problem (and whether other users have it too).
- Impact: how many people, which department, whether there is a workaround.
An example:
| Weak | Useful |
|---|---|
| "Prescribing doesn't work." | "In the adult ICU, when saving a prescription with an antibiotic on a custom schedule, the message 'Error saving item' appears (full text attached). It has happened since 8 a.m. today for every ICU physician; other units work. Workaround: prescribe on the standard schedule and adjust it in the administration schedule." |
Showing the error without exposing the patient
A screenshot helps support, but a Tasy screen almost always shows name, medical record and clinical data. Before attaching one:
- cover the name, documents, record number, date of birth and any clinical data;
- reproduce the error with a test patient in the training environment, when the hospital has one;
- copy the text of the error message instead of capturing the whole screen;
- never send the screenshot through a personal messaging app or an e-mail outside the hospital's channels.
A screenshot with patient data outside the hospital's environment is an exposure of sensitive data. On handling identifiers in data work, see pseudonymization in Tasy.
Priority
The hospital's protocol defines priorities. A common scale:
| Priority | When |
|---|---|
| Critical | Care stopped or patient at risk; no workaround |
| High | A whole department affected, with a laborious workaround |
| Medium | One user or one function, with a workaround |
| Low | Question, improvement, report adjustment |
A critical ticket is also reported by phone, in addition to the record.
A system problem or a configuration problem?
Many tickets are not Tasy defects: they are configuration (a pricing rule, a profile without permission, an item not registered) or process (a skipped step). Internal IT usually separates the two before escalating to the vendor. A profile without permission, for example, is solved by whoever manages access (access profiles in Tasy). For process questions and results-oriented configuration, independent consulting tends to help more than support; see Tasy consulting.
Closing the ticket properly
- Test the fix before confirming, safely (test environment or a controlled case).
- Confirm with whoever had the problem, not only with whoever opened the ticket.
- Record the cause and the fix in the ticket, so the next person with the same problem finds it.
- Correct what went wrong while the problem lasted: records made under contingency, accounts, inventory.
Support indicators
- Tickets by category (system, configuration, access, question).
- Time to resolution by priority.
- Reopened tickets.
- Repeated tickets for the same reason: candidates for training or for a permanent fix.
Repeated tickets often point to a gap between departments rather than a defect; see integrations in Tasy.
Who writes this
Domínio has worked for more than 20 years with hospitals that run Tasy and helps separate what is a ticket from what is a process. To talk about your hospital, reach us on WhatsApp or at comercial@dominiocontabil.com.br.
Related questions
Can I send a screenshot to support?
Yes, without patient data: cover the name, documents and record number, or reproduce the error with a test patient.
Who opens the ticket with the vendor?
Usually hospital IT, after checking that it is not a configuration or access issue.
What do we do while the ticket is open?
Follow the agreed workaround and record what was done under contingency, so it can be entered later.
How do we avoid repeated tickets?
Record the cause and fix of each ticket and turn the repeated ones into training or a permanent fix.
Written by the Domínio team behind Clic Health: accountants, controllers and developers with more than 20 years of work with hospitals that run Tasy. Have a question about Tasy? Talk to us on WhatsApp.