Build an EHR/EMR app on Rails

Build a brand-new EHR/EMR application from scratch with Ruby on Rails and Avo 4 as the management UI (https://avohq.io, docs at https://docs.avohq.io/4.0/). Nothing has been built yet. Everything must live inside my own infrastructure; patient data never leaves the app.

1. Scaffold the application with rails new using sensible defaults, then set up sign-in with Rails' built-in authentication generator so every clinician and staff member logs in. Add the avo gem, bundle, run bin/rails generate avo:install, and mount Avo at /avo behind that authentication so the back office is never reachable unauthenticated.
2. Work out the data model from first principles before touching a migration. Think through what running patient records genuinely requires: the core entities a clinical record turns on, the lifecycle each one moves through (model an encounter's status or a medication order's state as an enum, or as its own table when the workflow is richer than a few values), and how they associate into a navigable chart. The domain will surface patients and their identifiers, clinical encounters or visits, medications and orders, and attached documents such as scans and referrals, so treat those as ground your design has to cover, not a schema to transcribe. Sketch the tables and relationships, then write the migrations.
3. Generate an Avo resource per model with bin/rails generate avo:resource, then make each one concrete (https://docs.avohq.io/4.0/resources.html). Set self.title to a human label like the patient's name, list self.includes to eager-load the associations a chart renders so it stays fast, and set self.search over the columns staff look records up by. Match field types to the columns you chose: a date for a date of birth, a select backed by your status enum for an encounter, a files field over Active Storage for documents, and a visible lambda checking the current user on any protected field so it renders only for a role allowed to see it.
4. Turn the clinical verbs into Avo Actions rather than raw edits: admitting or discharging an encounter, prescribing or discontinuing a medication, flagging a chart for review. Since the app is new, put the real behavior in model methods or small service objects and have each action call into them, so a status change runs one code path whether it fires from Avo or elsewhere (https://docs.avohq.io/4.0/actions.html).
5. Add filters and scopes so staff can narrow to open encounters, a given clinician's patients, or active medications, and build a dashboard that surfaces what the page promises: active caseload, recent encounters, and documents awaiting review (https://docs.avohq.io/4.0/dashboards.html).
6. Make authorization the spine of the build with Pundit policies, the same ones the app uses (https://docs.avohq.io/4.0/authorization.html). Give a nurse, a billing clerk, and a physician distinct reach: write a policy for the patient record and one for each sensitive model deciding who views and edits what down to individual fields, plus attachment authorization so a document opens only for a role permitted to see it.
7. Seed realistic sample data so no screen is empty: a handful of patients, each with encounters across different statuses, medications, and a document or two, plus one user per role to sign in as.
8. Boot the app and open /avo. Sign in as the billing clerk and confirm protected clinical fields do not render and a document download is denied; then sign in as a physician and walk a patient into their encounters, run the discharge action on an open encounter, and confirm its status changes.