Referral Desk is a hypothetical startup building a referral portal for two clinics. The engineers have tested the referral form with fake records, and the clinics have set a date for the first pilot. Before staff enter real referrals, someone needs to check who can see them, where a failed submission goes, how the team would restore a lost record, and which vendor terms cover each step.
Put those questions on the launch plan and give each one an owner. When the team meets to decide whether to start the pilot, each owner can point to the contract, test result, or rehearsal that supports their answer.
Define the pilot you are actually preparing
For the first pilot, clinic staff can submit a referral, check its status, and add a note. File uploads, text reminders, and analytics are out of scope. With those limits, the team can trace a referral from the browser through the API to the database, then see what appears in the staff portal and what gets copied when an error occurs.
Record who can use the pilot, which features it includes, and the vendors, products, accounts, and regions involved. Keep the data map next to that list. If the team adds text reminders later, it can see where the new provider will receive data and send that path back for review.
HHS risk-analysis guidance addresses risks to electronic protected health information across the organization. This plan can supply information about the pilot for that wider assessment. HHS guidance on risk analysis
Make open work visible before it blocks the date
Referral Desk has two engineers and a privacy reviewer. The team can keep a short board that assigns each question to someone who knows what work remains and what evidence would close it. Choose checks that fit your app and review.
| Launch question | Owner | Evidence to review |
|---|---|---|
| Do the vendor terms cover the proposed use? | Privacy or legal lead | Agreed scope and signed or applicable terms |
| Can staff see only their clinic's referrals? | App engineer | Allowed and denied access tests |
| Do failures copy referral text elsewhere? | App engineer | Fake-marker checks in each destination |
| Can the team recover from a bad write? | Operations owner | Restore and app checks with fake rows |
| Who responds during a disruption? | Team lead | Rehearsed contact and response steps |
If the team is waiting on a vendor, keep the contact, next action, and follow-up date on the board. The engineers can finish the app tests while that question stays open.
Give the reviewer the agreement to assess the vendor's terms, and use the test results to show what the app does. Counsel can consult HHS's sample provisions when reviewing the actual arrangement. HHS sample BAA provisions
Rehearse the tasks staff will perform
Use two fake clinics with separate staff accounts. Submit a referral as Clinic A, read it back, and add a note. Then sign in as Clinic B and try to read that same record by its ID.
Even if the page hides the link, Clinic B can still ask the server for the record by its ID. The server needs to enforce the clinic access rule on each request. Check lists, search results, exports, and attachments too if they are in scope.
Save the app version, what you tested, and the expected result for each check. If Clinic B can open the referral, hold that path until the team fixes the cause and reruns the test.
To check where failed submissions go, put a unique fake marker in a referral note and trigger a form error. Search the approved test logs, error tools, and support output for the marker. If you find the note somewhere new, check the capture settings as well as the app code to find what sent it, then update the map.
Rehearse a mistake and a handoff
Suppose a release writes incorrect values to a field in the referral database. The team needs a way to stop the bad writes and recover the valid records. Rehearse how to restore a backup and verify that the app can use the recovered data.
In a separate test setup, create fake referrals, take the relevant backup, and make a planned bad change. Restore to a safe point using the provider's supported process. Check row counts, clinic access, and the referral page in the app.
Record how long it takes until someone can use the app again. Separately, check how far back the team can restore and which later writes are missing from the copy. Decide how someone would recover or reenter those writes before the team relies on the plan.
Have the second engineer run the written steps. The primary operator can watch, but should avoid supplying missing commands or account access. Any point where the second engineer gets stuck becomes work to finish before relying on the plan.
Use fake data for the incident handoff too. Ask the backup person to find the release, locate the failed request, and use a synthetic case to reach the provider through the right support channel.
Control changes after the review
If Referral Desk adds file uploads the day before the pilot, the team needs to check where the files go, who can read them, and what happens to copies in backups or support. Set a date to settle the pilot scope and send any new service or data path back to its owner for review. A small visual fix may need a brief check, while a new analytics SDK can require a wider review of data handling.
When the team decides whether to launch, record what passed, what remains open, and who can approve the next step within their role. Give qualified privacy and legal reviewers the worksheet as evidence for their assessment.
Review Forte against those same launch gates
Forte can deploy a Service from a GitHub branch and show build and deployment status. The deployment guide can support the pilot's release rehearsal. Keep the branch, version, and synthetic checks with the launch record.
Ask about BAA scope and enterprise terms through Forte support before sending patient data. Name the hosting, request records, logs, database, backups, and support paths under review. Agreement scope needs to match the proposed use.
Check whether the proposed database tier meets the pilot's access, recovery, and availability needs and confirm which commitments are in writing. Forte managed databases are in Open Beta. Shared databases have daily backups kept for seven days, and support handles restores. Dedicated Postgres is in Closed Alpha and adds point-in-time restore on a single node. Forte database docs
If you'd like to discuss the pilot, use the form below with the target date and open gates. Bring requirements and owners. Leave out patient records, production payloads, and secrets so the first conversation can focus on the decisions still needed.