Your partner in navigating the ins and outs of prescriptions — at no extra cost.

Alto Pharmacy Technician

Alto Pharmacist

It’s official: Alto Pharmacy is a great place to work! We’re honored to join the community ofGreat Place to Work-Certified™ companies based on team member feedback and a rigorous assessment of our company’s culture and benefits.

Join us in delivering our industry-leading pharmacy care to millions of people across the country. As a member of the team, you’ll play an integral role in improving our customers’ quality of life and redefining what’s possible in pharmacy.

Be Part of a Great Place to Work — Join Our Team

Hear first-hand from members of the Alto technology teams.

Read the latest Alto blog posts covering healthcare, family health, managing diseases, and other Alto highlights.

Blog | Alto Pharmacy

To automate a manual, error-prone pharmacy workflow, we turned to event streaming. Here’s what we learned from one of the first Kafka use cases at Alto.

How We Used Kafka to Build an Event-Driven Automation Pipeline and Scale Our Pharmacy

Imagine this: You're at the doctor’s office, and your doctor just wrote you a new prescription. Minutes later, before you even check out with the receptionist, you already have a notification from Alto Pharmacy on your phone that your prescription is ready. All you have to do is pick the date and time that works best for your free courier delivery.

This is the future we’re building at Alto: a future where a prescription can be transcribed, billed, and verified by a pharmacist in five minutes, flat. To get there without dramatically increasing Alto’s head count, we need to automate much of the process, starting with the first step: transcribing, or intaking, a prescription.

As a pharmacy, we receive prescriptions in many different forms. Some are sent electronically, in a structured format, but others are handwritten, phoned in, or even faxed. To represent all of these forms in a single table, we previously required every incoming prescription to be transcribed by an Alto team member, who would answer questions like:

Whom is this prescription for? Is this customer already in our system?

Where did this prescription come from? Who wrote it?

What is the relevant prescription information (medication to dispense, quantity, days supply, directions, etc.)?

This manual process is both time-consuming and prone to human error, which, if uncaught, could impact our ability to process the prescription downstream. Furthermore, at our busiest times, it could take up to two hours for a team member to get through the pending intake queue — unacceptable if we hope to have prescriptions ready to schedule before people even leave their doctor’s office. 

Automating intake required close collaboration between three teams:

Data Science, who built the decision-making algorithms 

Data Engineering, who served up the results of those algorithms

Product Engineering, who used those results to automatically intake prescriptions 

To allow the teams to operate in parallel without toe-stepping — and in the language most suitable for each (the Data Science and Data teams prefer Python, while product engineers work mainly in Ruby) — we separated the code into two environments: 

1. Data Prod Interface (DPI), where the code for generating automation results lives

2. Wunderbar (our proprietary pharmacy operations platform), where the code for requesting and using those automation results lives

The key question: to establish robust communication between these two environments, should we use an API-based approach, or an event-driven one? Each has its pros and cons. 

Legacy approach everyone at Alto is familiar with

Existing enforcement of strong types and data

Difficult to scale with increased data & requests

Requires ongoing authorization / authentication

Infrastructure relevant to other business areas

Automatic retries, reprocessing, and queueing

Our existing infrastructure currently utilizes a hefty API-based structure, so there was a natural tendency to go down this path, but we knew that beginning to migrate services towards an event-based architecture with Kafka at its heart would help us in the long term.

Kafka is a framework implementation developed by LinkedIn, now open-source with the Apache Software Foundation. It aims to provide a unified, high-throughput, and low-latency platform for handling real-time data feeds. 

Alto uses Amazon Web Services as our cloud provider, and luckily, they offer an out-of-the-box managed solution for Kafka, MSK. To configure Kafka with our system, our infrastructure team worked with AWS to set up managed instances to comply with our business requirements. Our Infrastructure team will share more details about this work in an upcoming blog post. 

Kafka offers many benefits. The asynchronous nature of the message system allows for retries, reprocessing, and queueing as well as easy recovery from outages. In addition, the infrastructure work done for setting up the managed cluster would be a one-off workstream. When complete, we’d be able to re-use the same setup and configurations across various business needs to streamline other projects that leverage Kafka. 

Setting up for success: defining a strict contract

One element we had to get right from the start was the data contract. As we send messages between DPI and Wunderbar, we need to ensure messages are produced with the correct schema, so that downstream consumers know what to expect.

Protocol Buffers, or Protos, is an open-source, cross-platform data format used to serialize structured data. Developed by Google, Protos allow you to define how you structure your data once and then use generated code to easily write and read the structured data in a variety of different languages. 

At Alto, we’ve been using Protos for the past few years to speed up development with auto-generated code and ensure data continuity between our Ruby on Rails backend and JavaScript / React / React Native frontend. Protos may seem antithetical to JavaScript and Ruby since they’re both dynamically typed languages, but in practice, they have saved us countless hours of debugging and back-and-forth Slack messages. 

For this project, we turned again to Protos to define the schema for messages produced by DPI and Wunderbar. We defined IntakeAutomationRequest and IntakeAutomationResult messages in Go and generated the types (Sorbet, Flow, etc.), which both DPI and Wunderbar now refer to when producing or consuming messages.

Because Wunderbar is already configured to run on AWS and houses our existing intake logic, it was easy enough to send a prescription to DPI for automation. Where we would normally create a task for an operations team member to manually transcribe the prescription, we instead produce a message to our “request automation” Kafka topic using the ruby-kafka library.

Our consumer, instantiated in an executable that runs on a dedicated worker, consumes messages from a “receive automation” Kafka topic. First, the consumer verifies that a given message corresponds to a prescription we previously sent to DPI. Then, it persists any automation results included in that message. If the automation results are sufficient, we skip intake altogether. Otherwise, we create an intake task to be handled by an operations team member.

Because this project was among our early use cases for Kafka, we wanted to be prepared for the worst-case scenario: we produce a message requesting automation results, and for whatever reason—maybe DPI is down—we don’t hear back. For us, we defined a reasonable time frame as fifteen minutes, in order to avoid building up a large backlog of work that would have to be offloaded back onto our operations team.
To this end, we store metadata about the automation lifecycle in an intake_automation_results table, which includes timestamps representing when we sent a message to DPI and when we received a response back. A cron job runs every minute to check that table for rows where received_at is blank, and sent_at was more than fifteen minutes ago. If this occurs, we flag the prescription to be manually intaken by an operations team member.

The diagram below illustrates our intake automation architecture.

Intake automation is now live at Alto. We’re seeing prescriptions fly through in just a few minutes — during which time our automation creates a user profile if one doesn’t already exist, links the new prescription to that profile, and finds and bills the user’s insurance; a pharmacist reviews the prescription for clinical accuracy; and the user receives a text message to schedule their delivery. This single flow, prior to intake automation, once took up to four hours to complete!

Going from zero to one is quite a feat, and it wouldn’t have been possible without an event-based approach. Now that intake automation has laid the groundwork, we know that Kafka will only continue to provide exponential value to Alto as we grow and migrate more of our services to this event-based architecture. 

Interested in learning more about engineering at Alto? Follow us on LinkedIn.

Each type of user has a different product or set of products we’ve built for them. From within each product, we collect, transmit, process, and store a tremendous amount of sensitive information. However, our biggest area of security, privacy, and compliance risk is our internal pharmacy management tool called Wunderbar that is used by our operations (ops) users every day to process prescriptions. Securing access to Wunderbar is mission-critical to protect our data and our business, and, of course, we need our super-secure implementation to be super-smooth to avoid slowing down our hard-working ops users.

Developing Robust Authentication Using Rails, Omniauth, and Okta

Alto Pharmacy aims to deliver a better pharmacy experience for everyone who needs medication. To achieve that, we need to enable three different types of users:

Individual customers who need prescriptions

Healthcare providers: the nurses, doctors, physicians assistants, and other medical professionals who prescribe medications

Operations users: the Altoids who intake prescriptions, bill insurance, fill prescriptions, and more

We wanted to be able to change our Wunderbar session lifetimes without hampering either our security efforts or the usability of our product. Moreover, we wanted session lifetimes of other apps to be able to change appropriately with business risk. Before starting this project, we’d implemented a Google OAuth 2.0 authorization flow that allowed ops users to log into Wunderbar via Google and take advantage of transparent session refresh for a limited amount of time.

However, while Google Workspaces was (and is) great for our email, documents, and calendars, it isn’t as configurable or extensible as a proper SSO solution. One painful side effect of this limitation was that, in order to ensure our refresh sessions were limited to twelve hours in Wunderbar, any user of the Alto Gmail drive also had to log back in every twelve hours just to see email — even though there’s not nearly the same level of sensitive data in email.

Plus, our IT team had already picked the tool of the future: Okta. And the goal was to enable SSO, or Single Sign On: if we still used Google for SSO, it wouldn’t really be SSO!

It was clear we needed to move to Okta for authenticating in Wunderbar, too.

Okta is a big company with many different authentication mechanisms. For us, the big question was really: do we want to authenticate via SAML or Open ID Connect (OIDC)? There are a lot of great resources around comparing these two standards and what they’re good at; here’s a good chart comparing and contrasting parts of these two authentication flows:

From this Medium post, which is a great primer on the differences

For us, the most attractive thing about SAML is that it can be used to provision user accounts from your upstream IDP; for example, Okta could be configured to push username, email, group, role, etc., information to our platforms with which we could automatically provision user accounts.

In the end, we decided the OIDC implementation would provide for a very similar user experience to that which our operations users were already accustomed to, with the same capability to perform transparent token refresh.

This transition was pretty easy because we were moving from Google OAuth 2.0 flow to Okta’s OIDC flow. OAuth 2.0 and OIDC are very similar; just know that OAuth 2.0 is technically an authorization framework (once you have a user, what can they access) vs an authentication framework (actually identifying and validating the user). However, there were some odd things about our previous implementation, and I only had one person to blame for those choices: myself. It’s great to get the opportunity to re-implement our authentication system — in a fast moving startup, you rarely get the chance to revisit problems so soon!

The biggest issue at hand with our previous Google flow was the way in which I’d chosen to re-authenticate users whose Wunderbar sessions had expired. In this case, OAuth provides a handy mechanism: a refresh token. Here’s how access tokens and refresh tokens are exchanged from the client and the authentication server in OAuth 2.0 flows:

At the time, we had session lifetimes of 60 minutes when accessing Wunderbar. These cookies also lasted 60 minutes. We faced a problem: if somebody walked away from their laptop for 61 minutes after authenticating, when they came back, how could we make it so they didn’t have to go back through the Google OAuth 2.0-initiated login flow from the beginning?

My solution at the time persisted a secure cookie with the refresh token value client-side with a longer expiration length. Then, if the user didn’t have a valid access token, we’d simply present the refresh token back to the server and get a new access token all over again. This worked well, but exposing secrets to the client always presents a risk of compromise. Refresh tokens are longer-lived, so they're of even higher value to protect!

Okta’s documentation made it very easy to stand up a simple authentication server and set up a local development server. Okta has a great blog post guide with tools we were already using (Rails and Omniauth, specifically) to get up and running. Beyond that, our biggest challenge was ensuring that we had a smooth rollout.

There was an issue in how we’d test and use this flow in our staging environments, however. At the time we were working on this (early 2020), there were two issues:

Our sandbox environment URLs were non-deterministic and could be varied depending upon how an engineer user named their cluster.

Okta apps did not support wildcard redirects in their oauth redirect URLs. This controls where, upon hitting Okta’s servers, they should redirect your payload to handle the meat of authentication.

For a time, our clever infrastructure engineering team managed around these issues with the use of an intermediary keycloak server. However, Okta now supports wildcard redirects that we’re successfully using today:

The biggest functional change to our authentication flow was in our refresh flow. The biggest challenge in landing this change was in how we deployed it to end users in production.

We didn’t want to expose the refresh token because it presented too much risk. What do we do instead? Something a little bit risky, but that we preferred after threat modeling our scenarios. Security engineering is often about making tradeoffs given a number of constraints. Today, our session lifetimes are down to fifteen minutes, and our refresh lifetime for an active session (e.g. somebody making at least one request within this window) is 60 minutes. If somebody comes back after their access token expires, that’s fine; we’ve persisted the encrypted refresh token to the database, and we can use attributes from the expired but still cryptographically valid token in order to look that refresh token up.

This was crucial for Okta especially because Okta refresh tokens are valid for 100 days by default!

Disruptive change is hard. We didn’t want to disrupt the workday of our hard-working ops users who are caring for our many customers and provider partners. The biggest intent here was to keep a safety blanket fallback to the old authentication flow until we were quite confident in its functionality. This broke down into a multi-phase approach:

1. Dark-launch the new Okta flow hidden behind a URL and with a small allow-list of users (mostly just the Security team) assigned to the new application in Okta.

2. Ask for volunteers! These volunteers would go about their normal work day in a variety of functional areas (customer care, pharmacy, fulfillment, engineering) using Okta instead of Google.

3. Change the default login flow to use Okta, but keep Google working just fine as a secondary action hidden behind a URL.

This allowed us to always ensure that we didn’t disrupt peoples’ days too much!

We achieved our goals and now, nearly two years later, we’re successfully using Okta’s OIDC flow within our core pharmacy management app. What did we learn in the process?

Not every API is necessarily fully implemented in every client. At the time of implementation, Okta’s Ruby client wasn’t fully supported. In order to support our refresh flow, we needed to upstream a small change into the client library, which required a little investigation.

Exposing secrets involves risk! In our case there wasn’t a glaring need to expose refresh tokens client-side at all.

Slow rollouts are great, especially with disruptive changes! A big thank-you to our team members who were willing to be part of the experiment group last year when this rolled out.

Interested in learning more about engineering at Alto? Follow us on LinkedIn and check out our open positions.

Last year, we set out to tackle this technical debt by splitting the User model into separate concerns and refactoring the entire system into this new paradigm.

Tackling Technical Debt and Improving Security: How Alto Untangled an Overloaded User Model

At Alto, we have three types of users: customers, healthcare providers (nurses, doctors, etc), and operations users who run the pharmacy. For each type of user, we maintain a separate application (though they share a monolithic backend for now): our customer app; our Alto Connect app for providers; and our internal pharmacy management tool called Wunderbar, which powers the pharmacy experience from prescription intake to fulfillment.

Early on, we made the pragmatic choice to represent both customers and operations users with a single User model, distinguishing them with a “roles” attribute. This required repetitive checks that, over time, slowed down our engineering teams, presented substantial privacy risk, and posed difficult scaling challenges as we evolved our monolith into different microservices. 

The challenges of relying on a single User model for different types of users

The notion of a User is core to our concept of identity from which authentication and authorization proceeds. From a security perspective, it’s difficult to build an extensible and clean authentication and authorization system when you’re overloading one model for two very different populations of users. From a privacy perspective, this muddied customer records (which are subject to more restrictions because they’re healthcare records) with workforce records, hamstringing many analytics efforts.

Authentication: Alto employees who were also Alto customers were required to use their work emails for their customer accounts. Not only was this restriction frustrating for Alto employees, but it also posed a security risk: employees should only be able to access Wunderbar via corporate SSO, not their personal account passwords. 

Authorization: Engineering new authorization capabilities required intricate knowledge of the idiosyncrasies of our user structure. This both slowed down development and created tremendous risk that any mistake could easily escalate user permissions.

Privacy: Because they existed in the same table, both customer records and Alto operations user records were classified as Protected Health Information, or PHI, which severely limited what we were able to do with them.

Attribution: Our robust audit logs were significantly less useful when a user ID in the transaction log might refer to either an ops user or a customer.

State management: Some updates pertaining to admin identity lived on the customer model, some lived on the employee model, and others lived in other various models.

Architecture: Tight coupling would have prevented us from decoupling our monolithic system into smaller services.

Our backend is primarily a monorepo Rails application that shares a tremendous amount of functionality between our customer, provider, and ops user-specific domains. Generally we use JWTs to secure customer and ops user sessions. These JWTs are issued only once valid credentials have been present.

Ops users are required to log in via Okta SSO, enforcing both valid username/password as well as a two-factor authentication (2FA) prompt. We use Devise and Omniauth to wire up the OIDC flow with our upstream identity provider, and we use CanCan to expand a set of roles per-user into a set of capabilities that restrict what resources they can access/modify.

Ops users primarily work in our internal pharmacy management app. However, the state of these users was shared between several different tables: Users, which otherwise refer to customers, and Employees, which share some ops user-specific state tied to Users.

Large change sets of code being deployed at once are harder to code review, harder to unwind if something goes wrong, and are more likely to be more disruptive. For this project, we knew that such a large architectural change had to be broken up into many more-digestible pieces if we were to be successful. The plan:

1. Create a new dedicated model for our ops users

# == Schema Information
#
# Table name: wunderbar_users
#
#  id                        :bigint(8)        not null, primary key
#  user_id                   :bigint(8)        indexed
#  email                     :string           not null, indexed
#  first_name                :string           not null
#  last_name                 :string           not null
#  token_last_invalidated_at :datetime
#  roles_mask                :integer          default(0), not null
#  title                     :string           not null
#  team                      :string           not null, indexed
#  is_active                 :boolean          default(TRUE), not null
#  slack_user_id             :string
#  pod                       :string

This was the easy part: create the database structure for a properly isolated admin user type, which we called a WunderbarUser.

We now had our admin user state split between Employees and Users, with a new table that engineers and analysts wanted to use that was not yet populated, and we had to make progress while allowing new hires and new customers alike to onboard to our platform.

2. Synchronize state between the old tables and new table

Next, we created a WunderbarUser for any User who was, or ever had been, a Wunderbar user. This required some historical digging —we had a lot of people who were onboarded, and even some offboarded, before we even had the intermediate Employee record!

Two major choices at this stage really helped the project succeed. First, we ensured that the WunderbarUser records all had IDs matching the corresponding User records. This is because a lot of our legacy audit records (that we’re required to preserve and keep useful as a Covered Entity under HIPAA) referenced an `admin_user_id` column populated with the ID of the User. If we just created all new entries for WunderbarUsers, these old logs would require at least one level of indirection (e.g. querying back to User) to make useful.

     # Create with the same ID as the user that we're creating this from.
     wunderbar_user_attributes = {
       id: user.id,
       user_id: user.id,
       email: user.email,
       roles_mask: user.roles_mask,
       date_of_birth: user.date_of_birth,
       token_last_invalidated_at: user.token_last_invalidated_at,
       first_name: user.first_name,
       last_name: user.last_name,
       preferred_first_name: user.preferred_first_name,
       is_active: false,
     }

Second, we created a new WunderbarUser any time we created a new Employee record (e.g. when we onboarded a new employee) and synchronized any changes between Users, Employees, and WunderbarUsers tables. As a side note: we knew we’d have to protect this syncing logic to ensure that we only copied each change once — otherwise, our callbacks would fire forever!

3. Migrate functionality slowly to use the new ops user model

We migrated logic to reference WunderbarUsers where previously we’d referenced Users and/or Employees. Authentication, authorization, audit logs, and pharmacist licenses were all updated here — albeit painstakingly!

We then migrated all of the foreign keys our various Postgres database tables held to either the Users or Employees tables to instead reference the WunderbarUsers. This ended up being around a hundred foreign keys, but a constraint-only migration that fortunately didn’t involve any data changes.

In short: our goal was to do this change slowly and steadily enough that nobody would notice until, one day, we could announce to the team, “Hey, we did a big security-pertinent project, and now you can change your customer email to be anything.”

Authentication: While we use the same JWT format for each, our customer and operations user authentication systems are now totally separated.

Authorization: With separate user types, we have separate capabilities and domain-specific authorization checks for each area, enforced in code.

Experience: Onboarding as a new Altoid (somebody who works here; come join us!) is totally separate from the customer experience, and you no longer need to link your accounts together.

Privacy: Our ops users who choose to be customers enjoy the full privacy afforded to our customers without tying their account to their work identity in any way.

Attribution: Legacy audit logs are still index-able and query-able with the same IDs, just in a slightly different table.

State management: Customer state lives on the User table, and ops user state lives on the new WunderbarUsers table. Our callbacks on each have been dramatically pared down, and our intermediary Employee table is entirely gone, along with a number of other now-ancillary tables.

Architecture: We have a clear path to federate RBAC checks without shipping our entire customer database between services.

Bonus: Performance and code readability generally improved by removing complex joins and join tables and isolating concerns between the customer and ops user domains.

Another Bonus: Significant refactorings and increased test coverage along the way while we cleaned up some very old, very stale code.

Large architectural changes of legacy systems with heavy use are rarely 100% smooth. Here are a few learnings to keep in mind the next time you tackle a hefty piece of technical debt. 

1. Always validate your assumptions (e.g. the data your constraints are against) when foreign keys are concerned. Multiple times we assumed, “Hey, we’ve migrated a bunch of really big tables that are really old (insurance claims, prescriptions, and more), so there’s no way we could have another admin user that we haven’t created a commensurate WunderbarUser for, right?” Wrong! Your data can always have inconsistencies, but a simple SQL query (e.g. validate that all values of the column you’re migrating the foreign key to have a matching WunderbarUser) can save a lot of time and headaches.

2. When migrating foreign key constraints on tables with active reads in Postgres, ensure you break it into two steps. Migrate your foreign key with `{ validate: false }`

 def up
   remove_foreign_key :inventory_orders, to_table: :users, column: :created_by_id
   add_foreign_key :inventory_orders, :wunderbar_users, column: :created_by_id, validate: false
 
   validate_constraint
 end

Validate the named constraint of your foreign key separately

 def validate_constraint
   validate_constraint_statement = 'ALTER TABLE "inventory_orders" VALIDATE CONSTRAINT "fk_rails_abcd1234";'
   ActiveRecord::Base.connection.execute(validate_constraint_statement)
 end

3. When working with legacy tables, be mindful of legacy systems. Our Billing service used a very outdated golang ORM that panicked if a column specified by the `struct` in source no longer existed; this caused a late-night outage that made auto billing requests back up the next day.

4. Scoping projects is hard! This was a larger project than our team had ever scoped and delivered before. Once all the dust settled, this project took several months longer than our initial scoping estimates.This project was worth doing, but better estimates allow us to prioritize better. If we’d had a great scope of this immense project upfront, would we have chosen to do it first? Also, this was a tremendously difficult project to separate into material stages; all the benefit was really backloaded.

In the end, this was a very satisfying and important project to complete. We wouldn’t have been able to accomplish it without a lot of help from our colleagues on the Platform team, the Security team, and across many other functions atAlto. Very large projects that involve a lot of moving pieces and impact other teams are always scary — but we can’t let that fear prevent us from making the changes we know we need to do in order to be successful long-term.

The Engineering Team is hiring! Learn more about open positions here.

In honor of National ERG Day, which falls on November 17 every year, we’re highlighting the important work of Alto’s six ERGs. 

Celebrating National ERG Day at Alto

The history of employee resource groups (ERGs) in the U.S. dates back to the 1960s, when a group of Black employees at Xerox self-organized to discuss their experiences of workplace discrimination and advocate for more inclusive policies. At the time, these networks of employees united by a shared identity or experience were known as affinity groups.

Today, ERGs can be found at companies of all sizes and industries where they play an important role in shaping an inclusive culture and fostering a sense of belonging in the workplace. In honor of National ERG Day, which falls on November 17 every year, we’re highlighting the important work of Alto’s six ERGs. 

At Alto, we believe that every perspective matters, and that diversity fosters creativity and leads to innovation. Our six ERGs are part of our broader commitment to diversity, equity, and inclusion (DEI), both in creating our company culture and delivering an exceptional pharmacy experience.

"At Alto, we’re committed to building and sustaining an inclusive workplace that both supports our employees and helps us deliver on our mission to improve the quality of life for everyone who needs medicine,” shared Ty Bledsoe, Head of Diversity, Equity & Inclusion. “Our ERGs help foster authentic relationships, offer safe spaces for education and conversation, and celebrate the incredible diversity of our Altoids and our communities."

By building community, providing support, and contributing to an individual’s personal and professional well-being, these groups help ensure that every Altoid feels a sense of belonging each day at work and that we appreciate the diversity of the customers we serve.

Here are just a few ways that each Alto ERG contributes to a more inclusive culture and pharmacy experience.

Umoja’s mission is to inform, educate, and empower Black Altoids and allies. The group has deepened Altoids’ understanding of the Black experience by sharing educational resources in support of Black History Month, Juneteenth, and Pride.

They also help our team explore the intersection of identity and healthcare as it relates to our services. After Dr. Reverend Stacey Edwards, founder of Fertility for Colored Girls, spoke at Alto about the fertility journeys of Black families this spring, Umoja continued the conversation by inviting Dr. Temeka Zore, OB GYN and reproductive endocrinologist at Spring Fertility, and Esther Ebeuhi, a licensed doula and birth equity analyst, to speak on Black motherhood.

Alto Auténtico aims to build community among Latinx Altoids and ensure that they have a voice at Alto. In addition to facilitating company-wide learning about the Latinx experience and the diversity within Latinx culture, Alto Auténtico’s mentorship program connects junior and senior Latinx team members for coaching sessions and professional development. The group is also working with Alto’s operations, product, and marketing teams to establish a bilingual team to better support Spanish-speaking individuals using our pharmacy services across our communities.

Proud unites LGBTQ+ Altoids and allies in creating an environment where all Altoids can be their most authentic selves. The group has led Alto in celebrating important LGBTQ+ awareness days with events such as drag queen bingo nights for Pride and LGBTQ+ history month. Two Proud members who identify as bisexual gave a talk for Bi Visibility Day on September 23 and also shared their experiences of coming out in in observance of National Coming Out Day on October 11.

Proud also invites experts to speak at Alto about a range of LGBTQ+ issues. They recently hosted a session with Chris Tompkins, author of Raising LGBTQ Allies: A Parent’s Guide to Changing the Message from the Playground, and a fireside chat with Dr. Lisa Capaldini, who has focused on HIV since the beginning of the epidemic.

Women of Alto + Allies (WOAA) helps create an inclusive community for women at Alto with mentorship and networking opportunities that advance their leadership potential. Their newly launched initiative, WOAA Project Spotlight, celebrates female-identifying team members who have helped us deliver on our mission while living our values, and a quarterly webinar series shares how various self-identifying Altoid women launched their careers.

Working Parents + Allies facilitates discussion and collaboration in celebration of our working parents. The ERG has led Alto in supporting working parents with a variety of initiatives, including a community event with the Kids & Art Foundation’s Purvi Shah in honor of Bereaved Parents Month this July; an “Ask a Parent Anything” Slack advice hotline for parents, caretakers, and allies; and free access to Outschool’s live online classes for kids ages 3-18.

And with their second annual Holiday Giveback Program, which donates gifts to kids and families in need through Marine Toys for Tots and the Boys & Girls Club of America, Working Parents + Allies is an example of how our ERGs look for opportunities to give back and show support beyond the immediate Alto community.

During Asian American Pacific Islander month, the Asians ERG shared resources for individuals like Modern Health's Healing Asian Communities Circles and highlighted community groups for volunteerism and donations.

To learn more about any of our employee resource groups, contact the emails below.

Women of Alto + Allies: womensERG@alto.com

Working Parents & Allies: parents@alto.com

Visit alto.com/careers to learn more about our open roles and join us in delivering industry-leading pharmacy care.

We’re excited to welcome Ramiah Martin to Alto as Vice President, Operations & Supply Chain. Here’s more on what drew him to Alto and the opportunities he’s most excited about, in his own words. 

Meet Ramiah Martin, VP, Operations & Supply Chain

We’re excited to welcome Ramiah Martin to Alto as Vice President, Operations & Supply Chain. Prior to joining Alto, Ramiah was Senior Director of Operations at Amazon, where he developed the strategic vision for the company’s operations and led a cross-functional team in implementing new processes and technologies to streamline use of resources.

His dedication to continually improving the customer experience is matched by a passion for healthcare change, and we could not be more thrilled to have Ramiah on the team. Here’s more on what drew him to Alto and the opportunities he’s most excited about, in his own words. 

Welcome to Alto! What inspired you to join the team?

When I first learned about Alto, its mission and values stood out to me first and foremost. I immediately felt a strong connection with the company’s mission of improving the quality of people’s lives through medicine and its commitment to putting customers first.

I was compelled by the opportunity to truly make a positive impact and help transform an industry that is both in need of improvement and slow to evolve. Through my previous experiences in operations management at Amazon and UPS, I know that streamlined processes can have a massive impact on a company’s results. At Alto, all of those efforts to innovate and maximize efficiency are in the service of driving broader change within pharmacy and healthcare.

I also appreciated that Alto is intentional about investing in talent representative of the communities we serve. As we continue to grow, and our customer base diversifies, it’s critical to have that diversity represented in the people building our new model for pharmacy care.

What is the focus of your role and what opportunities are you excited about?

As Vice President of Operations & Supply Chain, I’m focused on creating a scalable and sustainable organization, ensuring that as we grow, we continue to deliver an exceptional experience for our customers.

We have a great opportunity to ensure that individuals who have been historically underserved by medicine receive the standard of care that they deserve. I believe in the product — we make it as simple as possible to manage your health and learn more about medication and pricing, and our customers’ medication adherence rates are far above industry standards. I know there’s a lot more we can accomplish, and it’s a privilege to lead a team that’s united by a bold vision for healthcare.

I love movies, except for horror (Michael Jackson's “Thriller” video and Children of the Corn scarred me). I will go to the movies by myself as long as I have my Cherry Coke. It’s my way of shutting off my brain for an hour or two and relaxing.

You can find more information about Ramiah or connect with him directly on LinkedIn. If you have any questions about Alto, or are interested in joining our team, please visit alto.com/careers.

October 11 marks National Coming Out Day, an opportunity to celebrate all those who have come out as LGBTQ+ and recognize the courage they’ve demonstrated by choosing to be their authentic selves.

Celebrating National Coming Out Day at Alto

October 11 marks National Coming Out Day, an opportunity to celebrate all those who have come out as LGBTQ+ and recognize the courage they’ve demonstrated by choosing to be their authentic selves. In honor of this annual celebration, we sat down with two Alto team members — Ben Romero (he/they), Business Operations Manager for Health Plans and Travis White (he/him), Senior Software Engineer — who generously shared their experiences of coming out as bisexual/queer. Here are their stories, in their own words.

Ben: Like a lot of folks, I avoided coming out for most of my life. I grew up knowing that I wasn’t exactly straight and later recognized that I’m bisexual. I remember my entire experience around my sexuality being wrapped in shame. I would reluctantly conform to heteronormativity just to avoid the fear of being outed or questioned. It wasn't until college that I first felt like I could open myself up to the experience and validation that I deserved. By the time I graduated from college, I had a refreshed sense of my place in the world, but I was still hiding my sexuality from my family.

Five years after college, I was finally ready to be open with my family about being bisexual, and it was the first time I felt as if I had to “come out.” At the time I was engaged to my non-binary/queer partner. My family knew my partner as a woman, but my partner was also beginning to validate their nonbinary gender experience. All I could think about was how much of a disservice it would be to our identities as a queer couple if we started our marriage having to assume more invalidating heteronormative assumptions. I first told my closest family members — my younger brother and parents — who supported me unconditionally and showed me so much love. Not every family member was as accepting of my sexuality, which was really disappointing, but I had more than enough support from my chosen family to finally overcome the fear that I had held on to for so long. 

Travis: I realized I wasn’t completely straight at some point in high school. Growing up Catholic, I was always taught that men are attracted to women and that being gay was a sin. So when I found myself attracted to both girls and guys during high school, I wondered what was wrong with me. I brushed it off and ignored that aspect of my sexuality for a long time, which I would later come to regret since it definitely fed into ongoing anxiety and depression in college.

I first came out to my closest friends during my junior year of college. By that point, I had fully accepted that I wasn’t straight, but I had never acted on my bisexuality. I had only dated girls, so my friends saw me as completely straight. I couldn’t quite figure out how to tell them, and it ended up happening organically while hanging out on a Friday night. We were playing a game around the table that required everyone to share something no one else knew about them. Something came over me and I decided to throw caution to the wind with a, “by the way… I’m bi.”  

I came out to my parents several years later when I was working my first engineering job out of college, living in Silicon Valley and loving life. I knew that if they chose not to accept me, it was going to be their loss. After a night out (and an amazing prime rib dinner) when they were in town, I told them that there was something I wanted to tell them about myself - that I am bisexual. My dad’s first response was, “What does that mean?” I informed them that it means I am attracted to both men and women, though more recently, I’ve come to think of myself as being attracted to interesting people regardless of the gender they identify as. My parents were very supportive, but truthfully I had reached a point where I could be accepting of the worst-case scenario. 

Ben: I was most grateful for the sense of relief I experienced. Despite facing criticism and homophobia from some of my siblings after coming out, I couldn’t shake the sense of pride I felt from allowing myself to be unapologetically queer and visible. I’m finally allowing this part of me to flourish and grow. It’s liberating to be radically honest with yourself and others, regardless of what anyone else may think. I’ve now come to identify with the term queer in addition to bisexual. Part of the growth I’ve experienced involves unlearning so much of what I’ve been socialized to believe about the gender binary, and I’m just now starting to understand where I exist outside of it.  

Travis: When I came out to my friends during college, we stayed up talking until very late into the night. I left feeling a huge weight lifted off of my shoulders — and so full of love and support from some of the people I was closest to.

And later when I came out to my parents, they accepted me with open loving arms, for which I’m grateful, but I was also prepared to move forward with my life even if they did not accept me as my true authentic self.

What resources, support groups, or communities did you rely on when coming out? 

Ben: The isolation of being in the closet can sometimes lead to stories or expectations of yourself that aren’t necessarily helpful, or true. For me, as a bisexual, some of those expectations sounded like “I’m not queer enough,” “I don’t fit into the queer community,” or “people won’t believe I’m bi/queer.” I looked to my queer friends and even to LGBTQ+ advocates on social media and was relieved to find that they had many of the same fears about coming out as I did. I found that learning from other people’s experiences could help validate my own feelings, even if we had a different orientation or gender. As a queer Latinx, I also sought validation from people who shared similar intersections around my identity, which helped me navigate the concerns I had about coming out to my family.

Travis: My friends were very supportive so I was really able to lean on them. It was also helpful to just search online for other people’s coming out stories. Before I could tell my family, I knew I had to reach a point where I would be secure in my identity regardless of the outcome of that conversation. Part of the reason it’s so important to share coming out stories is because hearing other people’s experiences helps inspire you to do the same.

What advice would you give to others considering coming out? 

Ben: Above all, put your safety first. Try your best to not take on the burden of guilt for not being your authentic self — that is not a reflection of you, but a reflection of how our environment can fail to provide the validation we deserve. Take your time and build your comfort with folks who will validate your experience. There’s a whole community of people who will back you up and care for you if someone you come out to is hurtful or invalidating. 

Travis: Do it if, and when, you’re ready. You can never control how others will react, so just accept that other people’s responses have nothing to do with you. It took me years to reach that point with my family. It can be incredibly tough, and you can never know in advance how anyone will respond, but if they cannot accept you for your true authentic self, there are plenty others out there who will.

Do you have any suggestions for allies? 

Ben: I would stress the importance of familiarizing yourself with queer history and how our struggle for acceptence has evolved over the years. The LGBTQ+ community and allies have so much to be proud of today, like the repeal of “Don’t ask, don’t tell” (a former U.S. policy that directed military applicants to not disclose their sexual orientation), the legalization of gay marriage, and more queer representation on our screens — just to name a few.

At the same time, while all of those are certainly celebratory milestones, I ask that allies also recognize that our pride comes from so much more than a handful of legislative victories over the last decade. Our pride comes from the queer folks who came before us and fought for our visibility by rallying voices to speak out against injustice. Allies can research events such as the Compton’s Cafeteria riot, the Stonewall uprising, or the works of the Combahee River Collective. Understanding this historical context is important for also understanding the intersectional nature of the LGBTQ+ struggle for acceptance and restorative justice. Even though we have much to celebrate, our struggle continues as we fight for those who are still excluded or marginalized. 

Travis: Listen. The number one thing you can do is to listen and accept what someone in the LGBTQ+ community is telling you as their truth. It may change in the future — and that’s okay! Sexuality and gender are not a binary, and both can be incredibly fluid.

For parents: how you discuss sexual orientations and gender identities at home can leave a lasting impact on your children. I remember asking my mother about her thoughts on gay marriage, and she shared a more traditional view of marriage as a union between a man and a woman. That stuck with me for a long time and is a key reason I waited so long to tell them who I truly am. Read your toddler a book about a gay couple that gets married, teach your teens about prominent members of the LGBTQ+ community (and why they’re important), and if your LGBTQ+ child asks you to drive them to gay prom, treat the scenario as completely normal — because it is.

Why is it important for you to work at a company that values diversity in all forms? 

Ben: For me it’s a requirement that a company I work for prioritizes diversity and inclusion. I appreciate that Alto provides visibility into the progress that we’ve made towards building a diverse team that reflects the diversity of the patients we build solutions for. We also hold space to identify the work that still needs to be done. It’s really validating to have your background recognized at company celebrations and events or in spaces like employee resource groups (ERGs)*. It’s also important that we do all we can in our everyday actions to foster a collaborative and inclusive environment — one where people feel comfortable enough to be their authentic selves and not like they have to mask their gender, race, neurodivergence, or any other part of their identity. 

Travis: The U.S. — and the world — is made up of so many different people. There’s diversity of thought and beliefs, educational experiences, socioeconomic status, gender, race, A homogenous company that doesn’t mirror that diversity  will never be able to serve the entire population, and will miss out on a lot of opportunities. Alto’s mission is to fulfill medicine's true purpose — to improve quality of life — for everyone who needs it. The key word to me is everyone, and to truly fulfill the promise of that mission, we need a company as diverse as our customers. I personally find it rewarding to work at a company that values diversity and has strong representation of many identities, because that’s how the best ideas come to fruition and ultimately how the most positive impact is achieved.

At Alto, we believe in a world where every perspective matters. Diversity fosters creativity and creates innovation, and we welcome candidates of all backgrounds, skill sets, and experiences. To learn more, read Why We Prioritize Diversity at Alto. 

For more information on how to make your workplace safe and equitable for LGBTQ+ team members, read 11 Simple Ways You (Yes, You!) Can Make Your Workplace More LGBTQ Inclusive. 

If you or someone you know is considering coming out, we encourage you to review these resources:

Parents, Families, and Friends of Lesbians and Gays (PFLAG) Recommended Reading: Coming Out

*ERGs are meant to empower community groups within an organization by directly linking decision makers and implementing policies that support the group’s specific needs. The groups often center around a shared identity or experience and focus on building community, providing support, and contributing to its members’ personal and professional well-being. By creating an open forum for employees to come together, discuss challenges and opportunities, and foster a sense of belonging, ERGs help both individuals and organizations thrive.

The Next Evolution of Our Company Values

A lot has changed at Alto since Matt and I first set out to transform the pharmacy experience back in 2015. (For one thing, we no longer work out of a storage closet.) In the past two years alone, we’ve quadrupled our team to more than 1,000 Altoids and opened new locations in Denver, Las Vegas, Seattle, New York City, Houston, Dallas, San Jose and San Diego.

Our mission — improving the quality of life for everyone who needs medicine — will never change, but a team of 1,000 needs a different recipe for success than one of 100. And as our team continues to grow, along with our geographic footprint, we’ve revisited our core values so that we can move forward with intention and clarity during this next phase of Alto’s journey.

Here are the values that guide our work today.

This was at the top of our founding values, and it’s still here. In fact, our resolve to put patients first has only gotten stronger — not because it’s what is best for the business, but because it is our only reason for being in business. Each member of our team strives to build a world where healthcare companies truly prioritize the needs of their patients, and we’ll do everything in our power to make that a reality.

My personal favorite of all our new values, dancing in the storm is about embracing the bumps in the road — and there are many when you’re taking on challenges within healthcare — and recognizing that you can always choose joy. We strive to help our teammates do the same by infusing a little bit of levity and laughter into the workday. It only takes one person to start a dance party!

Blog

How We Used Kafka to Build an Event-Driven Automation Pipeline and Scale Our Pharmacy

Developing Robust Authentication Using Rails, Omniauth, and Okta

Tackling Technical Debt and Improving Security: How Alto Untangled an Overloaded User Model

Celebrating National ERG Day at Alto

Meet Ramiah Martin, VP, Operations & Supply Chain

Celebrating National Coming Out Day at Alto

The Next Evolution of Our Company Values

Get to Know Alto Auténtico, our Latinx ERG

Get to Know the Team That Builds Alto's Customer-Facing Apps

Alto Pharmacy Named Great Place to Work®

Celebrating Women at Alto Pharmacy

All About the Thyroid

Switch to a better pharmacy.