A small team builds an app for a clinic to collect intake forms before visits. The team has a Business Associate Agreement with the vendor that hosts its database. While testing a failed submission, an engineer finds the full text of the form in a separate error tool. That finding gives the team another vendor and another copy of the data to review before patients use the app.
Start the review by drawing where patient data goes when a request succeeds, when it fails, and when someone needs to restore a backup or handle a support ticket. Give the map to the person reviewing each vendor's role and terms before you send real patient data down any of those paths.
Follow one intake form
Call the hypothetical app Intake Lane and use fake records to follow its intake process. A patient opens a link in their browser and submits a form to the API, which saves the answers in a database. Clinic staff can open the form in a portal, and the app sends a reminder the next day if any information is missing.
Draw the browser, API, database, staff portal, and reminder service. For each step, write down who receives the data and what they do with it.
A Business Associate Agreement, or BAA, sets terms for a business associate's use and handling of protected health information. The vendor's role depends on its work and the data involved. Your privacy or legal reviewer should assess that role using the actual flow. HHS business associate guidance explains the starting rules.
List each use separately if a vendor does several jobs. A provider that hosts Intake Lane might also keep its backups and give support staff access to error reports. With the three uses on the map, the reviewer can check how the provider handles the data in each case.
Add the paths that appear when something fails
When an Intake Lane form goes through, the API saves a row in Postgres. If the submission fails, the error tool could capture the request body, or a retry queue could save a copy until the API is available. If someone asks for help, a screenshot of the form might end up in a support ticket.
For each case, find out what gets copied, where it goes, who can open it, and how long it stays. Check the contents of email alerts and chat notices too, since either one might quote part of the error.
Use distinct fake markers for the form fields. For example, put a clearly fake note marker in the clinical text field and a different marker in the contact field. After a test failure, search each approved test destination for those strings. You can learn which fields traveled together without using a real patient record.
If the search comes back empty, confirm that the test event reached the destination and that you searched the time range it arrived in. Only then can the result tell you whether the tested event contained that field.
Give every path a row and a reviewer
Give each path its own row so the team can see which reviewer needs to look at a change. Intake Lane can start with the form, error, reminder, and support paths.
| Path | Data to inspect | Person who resolves the review |
|---|---|---|
| Browser to API | Form values, URL, and headers | App owner |
| API to database | Form and clinic reference | Privacy lead and app owner |
| API to error tool | Error text and captured request | App owner and privacy lead |
| App to reminder sender | Address, link, and message | Privacy lead |
| Staff to support | Ticket text, exports, and images | Support lead |
For each row, add the vendor's legal name, product, account, region, and contract reference. Record the decision and the reason behind it. Link to the test or design choice that supports any claim that patient data will stay out of a tool.
If a row is open, give it an owner and a next step. Keep that path limited to fake data while the review continues. This lets engineering make progress without treating an unanswered contract question as settled.
Use the worksheet to give your reviewer the facts they need to assess the app's legal role. They may also need to consider duties and rules beyond the paths you've drawn.
Treat encryption and scope as separate questions
Keep encrypted storage on the map and record who holds the key, how they use it, and who can request access. A cloud provider that stores encrypted electronic protected health information can still be a business associate even if it lacks the key. Give those details to your privacy reviewer when they assess the vendor's role and terms. HHS cloud guidance
Next, check the exact services covered by the proposed agreement. An agreement for a database product may not answer questions about a separate analytics feature from the same brand. Save the covered product list and any account or plan limits with the row.
Check backups and support in the same way. If a backup keeps a copy after the team deletes the live row, or a support engineer opens a ticket in another tool, record where that copy goes and ask how the terms apply to it.
Keep the map tied to code changes
When a pull request adds an SDK, changes an event field, or creates an export, ask which row on Intake Lane's map changes and who needs to review it. Tying the review to the pull request gives the team a chance to resolve new paths before they go live.
Keep one failure test that confirms the intended limit. In this example, an invalid form should produce an error code and request ID without copying the clinical text into general logs. Search for the fake marker after the test, and save the result beside the affected row.
Assign someone to review console settings too. A teammate can turn on session replay, request body capture, or support access without touching the app code, so the person who checks those settings should update the map when they change.
Place Forte on the map before using patient data
Forte offers enterprise BAA discussions. Describe the proposed workload and have your reviewer check which services and features the agreement covers before sending patient data. Forte support
For Intake Lane, name Service hosting, database storage, backups, request records, app logs, and support access. Review how those services operate as well as what the contract covers. Managed databases are in Open Beta, and dedicated Postgres is in Closed Alpha. Forte database docs
Use a test Service and fake forms to inspect the error path. The request debugging walkthrough can help locate the request and related app output. Your team still chooses what its code sends and which capture settings it enables.
To discuss fit, bring the synthetic map and the rows whose scope is still open. The form below can start that conversation. Share service roles and questions, without including patient details, raw production logs, or credentials.