An engineer on a clinic intake app is checking what happens when the API can't save a submitted form. They open the error report and find the whole request attached, including the fields for the patient's name and clinical note. If that capture stays on in production, the error tool could receive a copy of each failed form.
Check where those fields go before launch. Give them unique values in a fake form, trigger a few failures, and look for the values in logs, alerts, queues, and support output. If you find an unexpected copy, fix the source and repeat the test to see what the destination receives.
Build a test you can trace
In this hypothetical example, Clear Intake uses a browser form, an API, Postgres, and a separate error tool. Clinic staff use a support console when a submission fails. The team uses invented records to check what each part of the setup receives.
Give each sensitive test field its own marker. A fake note might contain FAKE-NOTE-4821, while the fake contact field uses a separate marker. Keep a short list of which marker went into which field. Distinct markers help show whether the app copied the full request or just one value.
Use reserved test addresses such as person@example.com, leave out real phone numbers, and send test output only to destinations approved for the rehearsal.
Before running the test, write down what each destination should receive. Clear Intake might allow a request ID, route name, status, and a fixed error code in its general logs. Those fields can tell an engineer that a database write failed without showing the clinical note. Review the fields against the app's own privacy and security requirements. OWASP logging guide
Cause failures at different points
A form that saves successfully may skip the code that captures a full request. In the test environment, submit an invalid field, send a request that should be denied, and cause a database write to fail or a dependent service to time out. Include malformed request data to check what the app records when the normal handler never runs.
| Test case | What might copy a field | Where to look |
|---|---|---|
| Invalid form | Validation message quotes the value | API logs and error event |
| Denied request | Middleware prints the request | Gateway and app output |
| Failed database write | Driver error includes query details | Exception and trace |
| Timed-out dependency | Retry keeps the original payload | Queue and retry record |
| Support escalation | Staff attach a screenshot or export | Ticket and alert destination |
For each case, save the test time, request ID, app version, and destination you checked. Confirm that the test event arrived before drawing a conclusion from an empty search. Open the full event too. An error tool may put request fields in a section you need to expand, even when the summary shows only an error code.
Follow the copies beyond the first error tool
Follow the data from the app logs to each approved destination on the map. The error tool may forward a notice to email or chat, while the retry queue may hold the original form until the next attempt. Check what the tools send automatically and what staff might copy, such as an event they download and attach to a support ticket.
Review headers, cookies, and query fields alongside the request body. If the app puts a record ID or search value in a URL, that value may end up in access logs, browser history, or error details.
If the design calls for a tool to receive no patient data, limit the fields the app sends and test what actually arrives. Ask a qualified privacy reviewer how to handle the remaining fields, since clinical text may contain sensitive information even after the team removes names.
Fix the output where it is created
Suppose the team finds FAKE-NOTE-4821 inside a validation error. Find the code or library setting that included the submitted value and check whether a fixed field name and error code give the engineer enough detail to debug the failure.
Build log events from the fields the app is allowed to send. A known error category can distinguish a denied request from a failed database write, while a request ID lets an engineer match the events across tools. A short list of allowed fields also makes it easier to review what a log contains when someone adds a new field to the form.
Check automatic capture separately, since an error SDK can attach a request body on its own. After fixing each source, repeat the same failures and search the events that arrive in the remote tools.
Treat a real-data finding as an incident question
If the team discovers real patient information in an unapproved destination, involve its privacy and security leads. Follow the response plan and preserve evidence through the approved process so the team can ask for help without spreading the affected payload.
Check retained events, backups, alerts, and downloads to find where copies may still exist. A qualified reviewer needs those facts to assess any reporting or other duties. Keep the work of containing and documenting the incident separate from the code change that prevents future copies. HHS Security Rule summary
Inspect Forte's capture and your app's output separately
Forte captures request records for Services that pass through its gateway. Request and response body capture is on by default in Sandbox projects and off by default in live projects, and you can change it per Service. Check the Service's setting and use fake data for the test either way. Forte monitoring guide
The body setting governs what the gateway captures. The app controls what it writes to its own logs. Trigger the same synthetic error and inspect both outputs. If the app includes Forte's request ID in a safe log field, you can match the request record with the relevant lines. Forte debugging walkthrough
Forte Websites, including server-rendered sites, bypass the Service gateway and do not receive these per-request records or metrics. Review what the Website itself logs and what browser error tools collect.
Before using patient data, discuss the proposed request, log, backup, and support paths with Forte and have your reviewer confirm the agreed BAA scope. The form below can start that discussion with a synthetic failure and your questions about capture. Keep real logs, tokens, and patient records private. Forte support