A team preparing to launch a clinic referral app has chosen cloud hosting and a managed Postgres plan. The cloud provider sends a Business Associate Agreement, or BAA, for review. Before the team signs, counsel needs to know where referrals will go in that setup, including what happens when a request fails or someone opens a support case.
Have the people building the app walk counsel through the products, accounts, and paths they plan to use. Assign someone to follow up on each open question about the terms, and rehearse the steps the team would need to follow during an incident or a restore. Use fake data until the required review is complete.
Describe the setup the BAA must address
In this example, the hypothetical app is Clinic Route. In addition to its host and database, it needs backups, request logs, error alerts, and a way to get support. For each of those services, give counsel the product, tier, account, and region. Show where the referral text goes during a successful request, an error, a restore, and a support case.
When the BAA refers to “covered services,” find the list it refers to and match it to the products and features in the design. Give counsel the wider terms too, so they can assess the proposed use and the duties that apply to the app. HHS sample BAA terms
Match scope to each data path
A BAA sets out permitted uses and duties for handling protected health information. Check how the proposed agreement applies to Clinic Route's API, database, backups, logs, and support access. If a product is outside the scope, work out what the team would need to change before using it.
The agreement may require the team to use a particular tier or complete an account setup step. Record who verifies those conditions and when they take effect so the app team knows when it can send data.
Put open questions on a shared worksheet and give each one a specific use for the reviewer to assess. If the API can capture request bodies, for example, ask whether the proposed BAA covers that feature for this Service in this account.
| Topic | Question to resolve | Person who follows up |
|---|---|---|
| Service scope | Which products, accounts, and uses are included? | Legal lead and app owner |
| Incident reporting | Who reports what, to whom, and when? | Privacy or security lead |
| Subcontractors | How do duties apply to other parties used? | Legal lead |
| Access and support | Who can inspect records, and by which process? | Operations owner |
| Record requests | How can required records be found and supplied? | Privacy lead |
| End of service | How are records returned, kept, or destroyed? | Legal lead and operations owner |
Keep the actual clause or document reference beside the answer. If the app team changes a product after the review, the team should be able to see which answers may no longer apply.
Rehearse an incident before choosing a contact route
Suppose an engineer finds a fake referral marker in a test error event. The team can use that event to ask where the host kept a copy, who can inspect it, and how they would contact the host if they found a real copy.
Check who owns the account, who can take over, and what information to include when they use the approved channel. Ask how the host will communicate about an event and have counsel review the reporting duties and timing that apply to that kind of event under the actual BAA.
Use the order form, support plan, or service terms to check whether a response target covers the time to reply or the time to restore service. Record each commitment so the person on duty knows what to expect.
Decide who saves evidence, who works with the privacy lead to learn who was affected, and who contacts customers. The host can supply facts about its service while the app team coordinates the response for its own app and customers.
Review backups and retained copies explicitly
Alongside the live database, check how the provider protects copies in backups, exported events, and support files. Ask who can restore or open those copies and how long the provider keeps them after the account closes.
Keep encrypted backups in the review because the provider may have business associate duties even if it lacks the key. HHS cloud guidance
Review the end-of-service terms with counsel, including what happens when the provider cannot return or destroy a copy. Confirm what the team can ask the provider to remove, which copies can remain in backups, and how long protections apply.
Agree with the customer on which records they need to keep and how they can access them after closure. Settle those questions while the team has time to test the export.
Test the last day of service with fake records
Clinic Route can rehearse leaving without moving patient data. Export a small set of fake referrals and load them into a separate approved test setup. Check that the app can read the records, show their clinic links, and preserve the fields it needs.
Record the export format, access required, and steps that needed provider help. Ask what happens to app access, support access, and billing after the end of service. Confirm which requests must be made before the account closes.
List the SDKs, credentials, callback URLs, and feeds the team would remove from the running app and its accounts. Put those steps beside the contract steps so someone owns the full shutdown.
Save the results with the worksheet and note how many records you used. The export can show which steps work for the test data, while a full migration needs its own estimate and the end-of-service terms still need review.
Bring a specific scope question to Forte
Forte offers enterprise discussions about HIPAA workloads and BAAs. Name the products and uses you plan to review, including Service hosting, request records, app logs, database storage, backups, and support access. Have counsel review the agreed scope before the team uses patient data. Forte support
Check the app's recovery and availability needs against the documented limits and written commitments. Forte managed databases are in Open Beta. Dedicated Postgres is in Closed Alpha and uses a single node. Forte database docs
Use the form below to share the product list and open scope, reporting, support, or exit questions. A flow that uses fake data is enough for this first discussion. Leave out patient details, private contract text, raw live records, and secrets.