A small software team is designing Cedar Portal, a hypothetical app that two clinics will use to open patient records and add notes. The team's first sketch shows a browser, an API, and a database, along with tools for analytics, search, and exports. Before picking those tools, the team traces what happens when a staff member signs in, opens a record, or saves a note. Those paths tell them what they need to run and review for the first release.
For each path, choose services whose terms, access controls, and recovery options fit the work. When the app needs another copy of patient data, add that path to the design and decide who will handle it.
Give the first portal a clear boundary
For the first version, the clinics need private staff access to their own records. Uploads, public sharing, and reminders are out of scope. The team can build and test this version with fake records.
The browser sends requests to a backend API, which checks the staff member and their clinic before it reads or changes a record. Postgres stores the records and their clinic assignments, and approved logs keep the details engineers need to investigate a failure.
Add backups, administrator access, and support to the drawing too. A staff member may never see those paths in the portal, but anyone reviewing the design needs to know how they affect patient data. Ask the app's legal and privacy reviewers to assess the full arrangement, including vendor roles and terms and the administrative, physical, and technical safeguards that apply. HHS Security Rule summary
Keep the browser behind clear server checks
When a staff member opens a record in Cedar Portal, the API checks their session to learn who they are. It then checks their clinic against the clinic on the requested record to decide whether they can open it. The API runs those checks again when the staff member saves a note.
Test both outcomes with fake records. Sign in as a staff member from Clinic A and open a Clinic A record, then change the ID in the request to one from Clinic B. The server should allow the first request and deny the second even though the session is valid for both.
For lists and search, have the database return only the records for the staff member's clinic. Use an index that supports the query and limit each page. If the app fetches every record and hides some in the browser, the response still exposes those records and grows as the clinics add more data.
Save each piece of data where it has a job
For this first portal, the API can read patient notes from Postgres when it builds the staff view. If a save fails, the app can log which operation failed and keep the note text in the database path.
Use one fake record to check that design. Give its note a unique marker. Save it, read it, and trigger a safe error on another request. Search the approved test logs and error destinations for the marker. If it appears in a general error message, inspect what copied it and why.
If the clinics later need search, reporting, or an export that creates a second copy, record which fields the copy needs, who can access it, how long it stays, and how to remove it. Update the vendor map and contract review so the reviewer can see exactly where the fields will go.
Check the copies and the roles that can reach them in each design. One provider may give an administrator access to broad log output, while a specialist may offer a control the app needs. Comparing the paths tells you where access would actually change.
Give backups a place in the architecture
Draw the backup beside the live database and note who can restore it and where the restored copy will run. Then ask the clinics how much recent work they could lose and how long they could wait to use the portal again. A daily backup may leave many hours of notes outside the most recent copy. Even if the team can restore to a more recent point, it still needs to test how long it takes to get the portal working.
In a separate test setup, save fake notes with known times, restore the data, and connect a test app to the result. Check that the notes and clinic links came back. Repeat the allowed and denied access tests after the restore.
Check which later notes are missing and decide how to recover them. If the restore creates a second database, plan when the live app will connect to it and how the team will handle writes while it makes the switch.
Choose providers for this exact setup
Bring the service list and data map to the vendor review. Ask about the specific product, account, region, support access, and backup handling. Review the signed or applicable BAA and covered services before the app receives patient data.
If you're considering AWS, compare each service and feature in the design with its current list and terms, including any conditions that apply to the configuration you plan to use. AWS HIPAA guidance
Your team still owns the code that checks clinic access, the data it sends to logs, and the people granted app roles. Put an owner beside each job. If a task is described as “managed,” ask what the provider actually does and what your team must request or verify.
Check where Forte could fit
Cedar Portal's API could be a Forte Service if the proposed workload and terms fit. Forte connects a Service to a GitHub branch and exposes its build and deployment status. Start with a synthetic version using the deployment guide.
If the team also hosts its interface as a Forte Website, that Website needs its own access checks for data it serves. Forte Websites, including server-rendered sites, run outside the Service gateway. Keep the record access rules in the API too if the Website calls a protected Service.
Compare the database's recovery and availability limits with what the clinics need. Forte's 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. Review those limits alongside the other patient-data requirements. Forte database docs
Discuss BAA scope and enterprise terms through Forte support. Name the API, database, backups, request records, logs, and support paths. Keep the design on fake data until the required reviews and checks are complete.
The form below can start a discussion of that bounded design. Describe what the portal must do, how clinics stay separate, and which recovery needs matter. Use a synthetic example and leave out patient details and credentials.