Avo for healthcare
Run patient operations from your own Rails app
Patients, appointments, providers, and documents, managed by your team from a command center inside your Rails app, with access decided per role and per field, and the data never leaving your infrastructure.
250+ paying companies · 2.7M downloads of the avo gem
| can see | front desk | clinician | billing |
|---|---|---|---|
| Appointment time and provider | |||
| Clinical notes | |||
| Diagnosis codes | |||
| Insurance and claim status |
The scheduler who books the room never renders the note attached to it, because a visible lambda on the field decides that before the page is built.
01 · the stakes
What health tech demands from an internal tool
In health tech, the internal tool is the part of the stack that can read every record and change any of them. That makes it the riskiest code you own, and the code least likely to have been built carefully.
-
01
PHI access has to be role-based and provable
A care coordinator, a biller, and a support agent should each see a different slice of a patient record. "Everyone with a login sees everything" is a finding waiting to happen, and a correct per-role, per-field access model is slow, exacting work to build by hand.
-
02
Who viewed a record matters, not just who changed it
In clinical and near-clinical systems, access itself is an event you may need to produce. Retrofitting that onto a bespoke admin, and trusting the log to be complete, is its own project.
-
03
The data cannot live behind a vendor's login
A hosted admin tool puts a third party in the path between your team and patient data, and that third party then appears in every security review and BAA conversation. The tool has to live where the data lives.
-
04
Ops waits on engineering for every fix
Merging duplicate patients, correcting an appointment, resending an intake form: when each one needs a console command, patient-facing work queues behind an engineering backlog.
02 · the Avo version
Your models are already the hard part. Avo is the rest.
Avo mounts inside your Rails app, so patient data never transits a third-party service the way it would with a hosted admin tool. You model patients, appointments, and documents as resources on your own tables, every access goes through the Pundit policies you control, and the operational verbs become logged actions your team runs themselves.
Access decided by policies, enforced everywhere
Avo reads your Pundit policies, down to individual fields. A field a role should not see, a diagnosis, a date of birth, an insurance ID, simply does not render, and the rules are Ruby in your repo, reviewable in a PR.
It lives in your infrastructure, not a vendor's
Avo is a Rails engine mounted in your app, so records stay in your database and requests are served by your servers. There is no external platform between your team and patient data, and nothing new to add to a compliance review.
The care graph as linked records
A patient has appointments, providers, and documents; Avo renders those associations as linked panels, so your team navigates a patient's history without you hand-building the UI for it.
Auditing you own, viewing included
Pair Avo with model-level auditing to record every change with the acting user, in your own tables. On Enterprise, Avo's audit logging also records who viewed a record, which is the bar health data is often held to.
Operational verbs as safe actions
Merge duplicate patients, reschedule an appointment, resend an intake form: each becomes an action with a confirmation step, so ops resolves it in seconds instead of filing a ticket.
An Appointment resource with role-gated fields and a reschedule action:
class Avo::Resources::Appointment < Avo::BaseResource
self.includes = [:patient, :provider]
def fields
field :scheduled_at, as: :date_time, required: true
field :status, as: :select, enum: ::Appointment.statuses
field :notes, as: :textarea, visible: -> { current_user.clinical? }
field :patient, as: :belongs_to, searchable: true
field :provider, as: :belongs_to
end
def actions
action Avo::Actions::RescheduleAppointment
end
end
# app/policies/appointment_policy.rb (Avo reads your Pundit policies)
class AppointmentPolicy < ApplicationPolicy
def show? = user.clinical? || user.scheduling?
def edit? = user.scheduling?
end
03 · the timeline
From first resource to the team running on it
Generate resources for your existing Patient, Appointment, and Provider models and you have a navigable view of real operations, with each patient's appointments and documents linked from their record.
Put it behind your existing authentication and add Pundit policies so clinical, scheduling, and billing staff each see only their slice, with sensitive fields rendering only for the roles allowed to see them.
Model auditing records every change with the acting user, the everyday fixes are actions ops runs themselves, and patient data still has never left your infrastructure.
case study · senior living care platform
“The beauty of Avo is that it provides enterprise-grade guardrails while maintaining full flexibility for customization. We're working from a point of confidence rather than constraint, knowing every development cycle delivers maximum value.”
04 · start today
Stand up your patient ops tool this week
Avo is per app with unlimited users, so the whole team works from it without the bill scaling with headcount. When you hit an edge Avo doesn't cover, you drop to plain Rails instead of filing a feature request.
Things healthcare teams build with Avo
Avo by industry
Avo for your team
Frequently asked questions
- Can I run healthcare operations on Ruby on Rails?
- Yes. Patients, appointments, providers, and documents are ordinary Rails models with associations, and Avo turns them into a navigable operations tool on top of your existing tables, with role-based access enforced by the policies your app already uses. Health tech teams like Mimi Care and Fabric Health already run their admin on Avo.
- Is Avo HIPAA compliant?
- Compliance is a property of your entire system and processes, not of any single library, so no gem can be HIPAA compliant on its own, and we do not claim Avo is. What Avo gives you is a better starting point: the tool runs inside your Rails app on infrastructure you control, access goes through policies you write, and the data never leaves your database for a vendor's servers. The compliance work, a BAA where applicable, encryption, retention, and access reviews, remains yours to do, on code you own.
- How does role-based access to patient data work?
- Access is enforced with Pundit policies, the same ones your Rails app uses, per action and per field. A biller sees what invoicing needs while clinical notes render only for clinical roles, and the rules are Ruby you review like any other code. See the authorization docs.
- Can we audit who viewed a patient record?
- Yes. Every access flows through policies and controllers you own, so you can pair Avo with model-level auditing to record changes with the acting user. On the Enterprise tier, Avo's audit logging also records views, which is the level health data is often held to.
- Where does the patient data live?
- In your database, inside your own infrastructure. Avo is a Rails engine mounted in your application, so unlike a hosted admin tool there is no external platform in the path between your team and patient data, and nothing is synced out to a third party.
- We're building an EHR. Is that a different setup?
- Same foundation, more depth on the clinical side: encounters, medications, and document authorization on top of the access model described here. We wrote up that build separately: build an EHR/EMR app on Rails.