Harbor Notes is a hypothetical clinic portal run by two engineers and a privacy lead. One engineer usually handles hosting, while the other builds most of the app's features. When the engineer who runs hosting is away and the portal stops saving notes, their teammate can open the console. To get the clinics working again, that teammate also needs the right permissions, the provider's support contact, and written steps for recovery.
When choosing a host for a small team, check whether someone can take over releases, access changes, backups, and incident response. Ask that person to follow the steps with fake data so you can find gaps before the team needs the plan for a live service.
Start with the work your team can cover
Harbor Notes has a staff portal, an API, and one database. As the team chooses between a managed platform and running more of the cloud setup itself, the engineers list the work they would do under each option. A provider might patch the hosts and take backups, for example, while the engineers test releases and decide when to request a restore.
Break a job like “operate the database” into steps someone can own. Name who checks backup status, who requests a restore, and who reconnects the app and confirms that staff can open the recovered notes.
Review the division of work with qualified privacy and legal reviewers. They need to assess what each party does and what safeguards apply alongside the terms of any Business Associate Agreement. HHS cloud guidance
Put a name beside each recurring task
Harbor Notes lists the provider's role alongside the team's duties. That gives the engineers a way to see who acts first and who takes over when one person's work depends on someone else's.
| Task | Provider question | Team duty |
|---|---|---|
| Release a change | What does the platform build and check? | Test app behavior and choose when to release |
| Change staff access | Which identity controls are supported? | Approve roles and test clinic limits |
| Keep backups | What is saved and for how long? | Review results and rehearse recovery |
| Restore service | Who starts a restore and when? | Check records and reconnect the app |
| Investigate a failure | Which logs and support routes exist? | Find impact and coordinate the response |
Assign a primary and backup person to each team duty, then give them individual accounts with the access they need. Separate accounts help the team tell who changed a setting and keep one password change from locking everyone out.
Keep the runbook, approved support contacts, and links to the right accounts where both people can find them. Put secret values in the team's approved secret system and document how to get emergency access.
Choose a review rhythm tied to change
Harbor Notes might check failed releases, backup warnings, new staff access, and unresolved provider tickets at a short weekly meeting. Choose a schedule based on the app and its risk review, and decide which changes need a check as they happen. If an employee leaves, review their access then. If someone adds a log tool, check its data path and contract before it starts receiving data.
Choose the review schedule as part of the wider safeguards assessment, which also includes how the team plans for a disruption. HHS Security Rule summary
Record what the team checked and what it did next. If a backup failed, a dated entry that identifies the backup and the action taken gives the next engineer enough detail to follow up.
Run a drill with the main operator absent
Create a separate test setup with fake notes and two fake clinic accounts. Choose a safe failure, such as deploying a version that cannot reach the test database. Ask the backup engineer to find the failed release, inspect the error, and return the app to a working version.
Have the main operator observe while the backup engineer follows the written steps. If the backup engineer gets stuck because they lack access or can't find the logs, record what blocked them so the team can fix it.
Once the health check passes, sign in, read a note, and save a change. Those extra requests check whether the clinic's staff can do their usual work after the recovery.
Then rehearse a data restore using the provider's process. Check which fake records return, when the app becomes usable, and whether clinic access still holds. Have the backup engineer explain what would happen to writes made after the chosen recovery point.
Save the steps and result with the test conditions. A live recovery can take a different amount of time depending on database size, provider queues, the permissions available, and the kind of failure.
Agree on provider handoffs before an incident
Use the terms for the account to confirm which channel accepts urgent issues, when someone is available, and what any agreed response target covers.
Then decide who contacts the provider, who tells the clinic how the incident affects its work, and who takes any reporting questions to the privacy lead. Link the plan to the actual BAA and service terms so the engineer on duty can check them.
Try that contact route with a harmless scope question before the launch. Confirm that the backup person is allowed to open the request. Use synthetic details and avoid copying patient records into a general support channel.
Ask the clinics how they would work while the portal is unavailable. Agreeing on a temporary process can tell the team how long the clinics can use it and when the portal needs to be back.
Assess Forte with the same work split
Forte shows Service build and deployment status and can connect request records with app logs when the app emits the request ID. Have both engineers use the deployment guide and monitoring guide in the test drill.
Your team still tests the app, checks clinic access, chooses what to log, and decides when to release or switch back. Check database maturity and restore steps for the tier, and use the written terms to verify any availability or recovery commitments. Forte database docs
Discuss BAA scope, support access, and any higher availability commitments through Forte support. These are workload-specific enterprise discussions. Save the agreed terms with the work split before using the setup for patient data.
To discuss fit, use the form below to describe who covers releases, access, recovery, and incidents. Name the jobs that lack a backup owner. Share operating requirements, without patient records, account credentials, or production log payloads.