Shop Alto Essentials to add pharmacy products to any prescription delivery!

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 of Great 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

When Jake Moffatt says he loves building things, he means it — sometimes literally. A construction project manager turned engineer, Jake has spent the past decade building software at mission-driven organizations. Today, as Engineering Manager of Alto Assistant, he leads the team that’s bringing wizard-like support to Alto’s customer-facing app.

Get to know Jake Moffatt, Engineering Manager on the Alto Assistant Team

When Jake Moffatt says he loves building things, he means it — sometimes literally. A construction project manager turned engineer, Jake has spent the past decade building software at mission-driven organizations. Today, as Engineering Manager of Alto Assistant, he leads the team that’s bringing wizard-like support to Alto’s customer-facing app.
Below, Jake chats with fellow engineering manager Mike Riess and recruiter Braden Hanlon about the work ahead for Alto Assistant.

I’d love to learn more about your background to get us started. How did you end up in software engineering?

When I was twelve, I started learning to code in QBASIC because I wanted to make video games. Once I wrote my first program, I was hooked! I loved computers and the creative power they gave to anyone willing to invest the time and energy to learn. Since then, I’ve built games, personal tools and projects, desktop software, and a number of apps and services — I love building things. My career has gone back and forth between construction and software engineering, but it’s been firmly in the software industry for the last ten years or so.

My favorite place to be in a company is working on something new that has a big impact or addresses an important problem. In a previous role, I built an app that helped people find roommates in a city where housing is prohibitively expensive. At that same company, I led the team responsible for creating a new vertical that eventually split off into its own company.

The goal of Alto Assistant is to help customers help themselves before reaching out to support. Our first project is introducing a wizard-like support “assistant” (hence the team name!) that guides the customer through a series of questions to narrow down the area of support. We’ve already identified a few tasks the assistant can help customers complete on their own, including making changes to upcoming deliveries or scheduling new orders.

In cases where we can’t help them just yet, our new tool generates data to help us to learn exactly what customers need help with. It’s a top priority to bake analytics into every new feature we build; even though we have years of experience supporting our customers — and we know intuitively which problems they frequently experience — we don’t have conclusive data to draw upon just yet.

We plan to start with a couple of frequent use cases and measure how often customers reach out to us for support. Then, we’ll chip away at the problem until we’ve seen a substantial improvement in the user experience. From there, we’ll move on to the next biggest problem and repeat the cycle. There’s a reason “Chip away it” is an Alto value: It’s the playbook that we’ve used to automate other critical parts of the pharmacy value stream like intake, billing, and fulfillment.

What opportunities are you most excited about?

Support drives much of the cost of every shipment today, so this is a high-impact area for our business. A year from now, it would be a stellar outcome if the Assistant team could reduce the number of issues that customers need support on by half.

We’re also thinking about the user experience beyond the app. We plan to improve the tooling that our care specialists use to provide support as well. We’ve already discussed some promising ideas like creating the concept of a conversation in support communications rather than an infinite stream of messages and building out enriched communications. We also intend to develop a custom tool that can expedite a customer’s prescription when they need their medication ASAP.

The possibilities are many, and it will take a team of determined, passionate, empathetic people to solve these challenging problems. I’m super excited to see what the Assistant team will do together.

Any lessons learned from previous experience that you’re applying to your role at Alto?

There’s always the temptation to tackle everything at once with new business initiatives. My experience leading new verticals at Apartment List and Snapdocs taught me the importance of being laser-focused on one or two key metrics instead of trying to build out a fully-realized product from the beginning. That’s exactly what we’re doing on the Alto Assistant Team with our clear focus on reducing communications per shipment — how often customers reach out for help because they could not find what they needed in our app.

It’s also important to recognize that we won’t have all the answers right out of the gate! I like to think of product development as a three-step sequence: learning, growth, and maintenance. Alto Assistant is so young that we’re very much still in the learning phase. We maintain a tight iteration loop with everything we ship: launch, measure the impact, and use the results to iterate and refine our hypotheses about what our users want. Our final product could be anything from a customer support wizard to an AI chatbot to a ticketing system — we have to rely on our key metric of communications per shipment, experimentation, and user feedback to shape the direction.

What got you excited to join Alto? What would you pass on to an engineer thinking about applying to the company?

I was impressed by the Altoids I met during the interview process. I knew I would be working with people from whom I could learn a lot, like Elnaz, who started as an individual contributor and went on to become Director of Engineering and, now, Alto’s first Head of Strategy & Operations. I was also impressed by the quality of the interview process itself — a good sign that the company was well-organized internally. Finally, the pitch for the role was extremely clear, with already-established key metrics that would directly contribute to the company’s bottom line and help Alto become more profitable.

For engineers, I think Alto is a great place for both technical challenges and career growth. We’re still small enough that every individual gets exposure to a broad portfolio of high-impact projects. It’s also a great environment for learning about how a business works — the Product & Technology organization does a great job of sharing information and presenting problems in a way that gets to the root business problem we’re trying to solve. There’s a clear line between any project a team is working on and a foundational business metric. Most importantly, we’re a company that makes a truly positive impact on our users’ lives.

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

We’re excited to share that Alicia Boler Davis will be Alto’s next CEO. She will start on September 1, 2022. This is a big moment for Alto, so we wanted to share how we got here.

Introducing Alto’s New CEO - Alicia Boler Davis

We’re excited to share that Alicia Boler Davis will be Alto’s next CEO. She will start on September 1, 2022.

This is a big moment for Alto, so we wanted to share how we got here.

Alto has come a long way since we started out in 2015 by acquiring AG Pharmacy in San Francisco. Those first few months revealed just how much opportunity there was to build a better pharmacy experience for patients by rebuilding the entire end-to-end technology stack, combining it with a more efficient operational process, and backing it all with a talented and caring team. And with that insight we started forging ahead with bright eyes and relentless optimism toward our ultimate mission: fulfill medicine’s true purpose - to improve quality of life - for everyone who needs it.

Like any transformational startup, the journey has not been without its challenges. We’ve been consistently humbled by the complexity of the pharmacy industry and the challenges inherent in transforming how it works. Yet we’ve also been consistently amazed by how much opportunity there really is to make a meaningful difference in the lives of patients, and how receptive people are to a better solution. And through persistence and grit, combined with an increasingly talented and diverse team, we have overcome all the challenges that we have faced so far. We have served over 300,000 patients, with a 90 Net Promoter Score, are unit profitable, and are expected to pass $1 billion in annualized revenue in the next few months. We’re making faster progress than at any point in the company’s history. 

So if things are going so well, why are we hiring a new CEO? The opportunity ahead of us is huge, and along with that the challenges are getting more complex. Despite how far we’ve come, we are still only 0.2% of the total pharmacy industry market share. Capturing this massive opportunity will require leveling up our already world-class team with an even greater level of bold, rigorous, caring, experienced leadership.

As we got to know Alicia over the past few months, we realized that we had found the perfect partner to lead us through the next phase of Alto’s growth. Alicia was most recently the SVP of Global Customer Fulfillment at Amazon, and before that the EVP of Global Manufacturing at General Motors. Alicia grew up in Detroit, and got her first job as an engineering intern at GM. Over the next 25 years she worked her way up to running a plant, then running multiple plants, then running all of quality and customer experience, and finally running all of global manufacturing. She was the first Black woman to accomplish each of these things at GM. In 2019 she joined Amazon, and was quickly promoted to the prestigious S-team, which is the exclusive inner circle of the most senior leaders at Amazon. When she was barely a year into the job, the Covid-19 pandemic hit, and over the next two years she oversaw Amazon nearly doubling its fulfillment network capacity to keep up with surging demand, while managing a team of over 800,000 people. Alicia built a reputation for successfully navigating the toughest challenges while driving unparalleled growth by bringing out the best in her teams.

From the day we started, we have always tried to build a team that is balanced between the rigor and operational excellence needed to execute in this complex industry, along with the heart and care that we saw was missing from the industry. These are not mutually exclusive attributes, but they are extremely rare to find in the same person. In Alicia, more than any other leader we’ve ever met at her level, we’ve found someone who can bring that balance that we seek. She is one of the world’s top executives in operations, and is a rigorous, disciplined operator. And at the same time, she leads with real heart and care for the people that she serves and that she works with.

With Alicia coming on board as CEO, Matt and I will continue to be involved full-time, both in supporting Alicia and with our own portfolios of projects to lead. We’re more committed than ever to Alto, and more excited than ever about the real opportunity we have in front of us. And we are so early in this journey that it is clear there is no shortage of work to do and problems to solve. Matt and I have never been attached to any particular role or title, and have each worn many different hats over the years. We are humble about what we are good at and what we are not, and just want to do what is best for our team in order to achieve our mission. In the short term we will focus on ramping Alicia up, and after that we will work more on what we do best: building our long term strategy, leveraging our entrepreneurial spirit to spin up new business lines, defining and evolving our culture, and sharing the Alto vision.

We are just getting started, and there is still so much opportunity to fix this broken industry, and truly help people live happier and healthier lives. We can’t wait to see what we will do together in this next phase of the Alto journey.

About 9% of men and 11% of women in the U.S. have faced fertility issues. These challenges may feel overwhelming, but there are a variety of treatment options for both male and female infertility to support your family building journey.

Here’s an overview of the causes and symptoms of male and female infertility and common fertility treatments.

Infertility, Explained

About 9% of men and 11% of women in the U.S. have faced fertility issues. These challenges may feel overwhelming, but there are a variety of treatment options for both male and female infertility to support your family building journey.

Here’s an overview of the causes and symptoms of male and female infertility and common fertility treatments.

Infertility, defined as the inability to get pregnant after twelve months or more of unprotected sex, is a health condition that affects both men and women. Approximately one-third of infertility cases stem from a female reproductive factor, one-third stem from a male reproductive factor, and one-third stem from a combination of both or unknown causes.

These are some common causes of female infertility.

The majority of female infertility cases are caused by problems with ovulation, the release of a mature egg from the ovaries. There are several causes of ovulation disorders, including the following.

Polycystic ovary syndrome (PCOS), a condition characterized by a hormone imbalance that impacts ovulation. It is the leading cause of female infertility.

Excessive exercise, eating disorders, or stress, each of which can result in hormonal imbalances

Primary ovarian insufficiency, sometimes referred to as premature ovarian failure

Fallopian tube damage or blockage can prevent sperm from reaching an egg, or fertilized eggs from attaching to the uterus. Common causes of fallopian tube damage or blockage include pelvic inflammatory disease — an infection of the uterus and fallopian tubes from chlamydia, gonorrhea, or other sexually transmitted infections — or a prior surgery in the abdomen or pelvis, including surgery for ectopic pregnancy.

Uterine or cervical issues such as the following can disrupt the implantation of an egg into the uterus or increase a woman’s risk for miscarriage.

Benign polyps or fibroids may block fallopian tubes or interfere with the implantation of an embryo. However, many women with these growths are able to conceive.

Structural issues with the uterus that are present at birth

Cervical stenosis, a narrowing of the cervix

Endometriosis is a condition in which tissue that should only grow in the uterus implants and grows elsewhere. The abnormal tissue growth — as well as surgical procedures to remove it — can block the fallopian tubes, preventing the fertilization of an egg. In some cases, endometriosis may interfere with implantation of the fertilized egg, or embryo.

Male infertility is most often an issue of sperm production — including the quantity and quality of sperm produced — or of sperm mobility, which affects the sperm’s ability to find and fertilize an egg. A blockage in the testicle or damage to the reproductive organs can also contribute to male infertility.

Age is a factor in both male and female fertility issues. The quality and quantity of a woman’s eggs begin to decline as she enters her mid-thirties, and age factors into the success rates of in vitro fertilization (IVF).

Many individuals and couples first learn of a fertility issue after trying to conceive without success, and the primary symptom of infertility is the inability to get pregnant. There aren’t always noticeable symptoms, but the following may indicate an underlying fertility problem.

A menstrual cycle that’s irregular, absent, longer than 35 days, or less than 21 days

Unusually light or heavy bleeding during menstrual cycles

Erectile dysfunction or low sex drive in men

The timeline for seeking fertility treatment depends on your age. If you are under the age of 35, most health experts suggest consulting a reproductive specialist after a year of trying to conceive. If you are between 35 and 40, you may want to pursue testing or treatment after six months of trying to become pregnant. And if you are over 40, you may want to pursue testing or treatment before you start trying to conceive.

An evaluation for fertility issues and potential treatment begins with a conversation about your health history. Several tests may be used during the diagnostic process, including the following.

An hysterosalpingogram (HSG), an x-ray taken to examine issues within the uterus and fallopian tubes

Blood tests to measure hormone levels related to fertility and reproduction

Ovarian reserve testing, which evaluates the number of viable eggs in your ovarian reserve. These are typically used for women over 35 or those at risk of a low egg count for other reasons.

A semen test is used to diagnose most cases of male infertility. This identifies how many sperm you produce and whether the sperm are normal in shape and movement — healthy sperm have an oval head and long tail. In some cases, additional blood tests and/or genital ultrasounds may be used to rule out other health conditions.

Fertility problems do not mean that you won’t be able to have children biologically. There are many treatment options that can help increase your chances of conception. The most effective course of treatment depends on the underlying cause of your or your partner’s fertility issues. These are among the most common fertility treatments.

Forms of assisted reproductive technology (ART) including in vitro fertilization (IVF), a process in which eggs and sperm are fertilized in a laboratory and then placed into the uterus with the potential outcome of a pregnancy. In addition to treating female infertility, IVF can also be used when male infertility is a factor.

Intrauterine insemination (IUI), a type of artificial insemination in which sperm that have been washed and concentrated are placed directly into a woman’s uterus during ovulation.

Injectable fertility medications including gonadotropins and oral fertility medications such as Clomid® and Femara® can treat fertility-related hormonal imbalances.

Your doctor may also recommend lifestyle changes or treating a related health condition.

A fertility pharmacy partner you can rely on

Since 2016, Alto has supported more than 50,000 fertility journeys. We understand that fertility treatment is a significant investment — physically, emotionally, and financially — and we see ourselves as a partner in your health.

We offer free, same-day delivery seven days a week and temperature controlled packaging to ensure that your fertility medications always arrive in the right condition. And our fertility-trained pharmacists are available until 9 pm PST (12 midnight EST) on weeknights to offer any support you need.

Reach out any time via phone at 1-800-874-5881, or in-app messaging.

This content is not intended to be a substitute for professional medical advice, diagnosis, or treatment. Always seek the advice of your physician or another qualified health provider with any questions you may have regarding a medical condition.

All third party trademarks (including logos and icons) referenced by Alto Pharmacy remain the property of their respective owners. Unless specifically identified as such, Alto’s use of third party trademarks does not indicate any relationship, sponsorship or endorsement between Alto and the owners of these trademarks.

We are honored to announce that for the second year in a row, Alto Pharmacy has been recognized by Forbes as one of America’s Best Startup Employers. This award celebrates our commitment to employer reputation, employee satisfaction and growth.

Alto Pharmacy Announced as One of Forbes Best Startup Employers for the Second Consecutive Year!

When Alto’s founders set out to transform the pharmacy experience, they outlined a vision whereby our work could improve the quality of life for everyone who needs medicine. Through this foundation grounded in helping people, we have built a company culture centered in care, inclusion, and impact. 

We are honored to announce that for the second year in a row, Alto Pharmacy has been recognized by Forbes as one of America’s Best Startup Employers. This award celebrates our commitment to employer reputation, employee satisfaction and growth. 

This recognition follows Alto Pharmacy's recent admission as a Great Place to Work-Certified™ company – awarded based on employee feedback and a rigorous assessment of Alto’s culture and benefits. Given the impact we strive to make on the communities we serve, we are humbled to share this most recent recognition alongside other accolades over the past year, including: 

The Healthcare Technology Report: Top 100 Healthcare Technology Companies of 2021 

The Healthcare Technology Report: Top 25 Consumer HealthTech Executives of 2021

The Healthcare Technology Report: Top 25 Women Leaders in Consumer HealthTech of 2021

These recognitions and achievements are only made possible through the hard work and dedication of the entire Alto team. If you are passionate about shaping the future of pharmacy, join us as we deliver our industry-leading pharmacy care to millions of people across the country.

For the full employers list and an overview of the selection methodology, head to the Forbes site.

Last summer, Moringa Fellows Irma Figueroa and Adrian Mendez joined Alto as the company’s second batch of engineering interns. Here, they share their learnings, accomplishments, and advice for future Alto interns.

Two Engineering Interns Weigh In: What to Expect From Your Alto Internship

The Moringa tree flourishes almost anywhere it’s planted. It’s hardy, fast-growing, and resistant to drought — an apt metaphor for the two interns who joined us from the Moringa Fellowship program last summer.

“Before Alto, I had never actually contributed to a large codebase,” admits Irma Figueroa, an intern on the Supply Chain Team. By the end of their three-month internships, however, Irma and fellow intern Adrian Mendez had shipped impactful features for Alto’s internal pharmacy management system and customer-facing app that are still in production today.

Below, we chat with Irma and Adrian to learn what it was like interning at Alto, which projects they worked on, and what advice they’d give to future interns. 

Adrian, who interned on the Patients Team before returning to join as a full-time software engineer last fall, was surprised by the freedom he had to choose what he worked on during his internship: “Early on, my manager gave me a rundown of the projects the team was juggling and the option to choose which one interested me the most,” he says. “I was able to decide the kind of experience I was going to have.” 

Adrian adds that meetings with his mentor evolved over the course of his internship, as he became more familiar with the codebase: “From the start, we had weekly meetings to talk about whatever was on my mind. Those meetings started off as general advice and questions and turned into more time to pair or run things by each other.”

Because both Adrian and his mentor were working on the same, long-term project, some of those meetings were also dedicated to project work. This included “sitting with [my mentor] while creating the project outline, pairing on larger tasks, and syncing up on progress.” 

Which projects did you work on during your internship? 

On the Supply Chain Team, Irma was tasked with a unique inventory challenge: Technicians at our production pharmacy locations use handheld scanners to scan the barcodes on newly-received inventory. Our technicians often need to scan hundreds of inventory items at a time — making it all too easy to lose track of which items have been successfully scanned onto which shelves. 

“I created a reusable counter component, displayed in the header of the scanner app, that would represent the number of items scanned into a shelf.” Irma says. The best part? Getting to test the handheld scanner herself. “I really enjoyed using the scanner for testing purposes. It was rewarding to see my code in action and definitely super fun!” 

On the Patients Team, Adrian worked on a project to add a homescreen to the customer-facing native app. Previously, the app dropped users into a list of all their active medications, which made it difficult to know where to look or what to do next. The new homescreen allows users to schedule the prescriptions most relevant to them and to view or edit any upcoming deliveries. 

“The first step was to create new additions to the design system — essentially taking the designs and extracting system-wide components. After that, the fun part was taking all those components and putting them together like building blocks!” Adrian says.

It was especially rewarding, he adds, to have been part of the project from start to finish. “I joined right as the design phase started, and I was there mostly every step of the way. For how short my time here was, having helped create this landmark project is really cool to think about.” 

What advice would you give to future Alto interns?

Irma and Adrian agree: Don’t be afraid to ask for help. “You'll often feel challenged and possibly intimidated, but be patient with yourself and remember you have an entire team of experienced engineers ready to help,” Irma says. 

“Everyone at Alto is more than willing to help you out, so don't be afraid to ask questions! You're on the same ship as everyone else, so your success equals everyone’s success,” Adrian adds. “Just remember that your work got you here, and they wouldn't have invited you if they thought you couldn't handle it. They made an investment in your ability to grow, so stay curious.” 

Interested in interning at Alto? Check out our careers page here.

With more engineers contributing to Alto’s codebase than ever before, we needed to establish better boundaries: which team owns what? Here’s how we developed a tagging-based solution to code ownership and drove and measured adoption.

How We Established Better Boundaries and Clearer Code Ownership at Alto

Some problems are nice to have. Over the course of 2020 the engineering team at Alto saw explosive growth, expanding from about fifteen to more than seventy individual contributors. Growth at this pace required us to rethink our team structures and priorities more than once. This growth felt amazing: the new capacity enabled us to make progress on our backlogs like never before.

But still, there were challenges. We saw a steady rise in merge conflicts as more people contributed to the same code base. Build times increased as more and more code was contributed. A big influx of new perspectives and talent also meant new gaps in historical context and responsibility. New teams took big bites out of their new priorities — great! But what about the old ones? Who was going to fix that bug? Who needs to review this PR? Who is accountable for this performance problem?

Who, in short, owned what? By the end of 2020, it was clear to us that a good, practical, working answer to this question would be the critical first step to continuing smooth, rapid, distributed iteration on our product.

Up to this point, the large majority of product development at Alto had happened in the context of a Ruby on Rails monolith, which — over a half decade of intense development — had grown pretty large. We’d stuck more or less to the default Rails convention of organizing code by function rather than feature, which meant that our code was distributed across a few mostly flat and very broad subdirectories such as '/models' and '/controllers', making it difficult to learn much about the structure and ownership of our business domains by merely looking at how the code was laid out. We knew that this was not going to work for us over the long term.

Our long term vision started to coalesce around a notion of “better boundaries.” First, we would modularize the monolith along the lines suggested by Shopify’s packwerk utility. Then, we would carve some of those modules out into separate engines that could be built and tested separately. Finally, we’d deploy and operate some of those engines independently as their own services. Clear ownership was fundamental to this plan: on either side of an effective boundary, you need to know not just what it is but also who owns it. We lacked that clarity.

The RFC (Request for Comments) we ultimately adopted opened with four questions:

How might we produce a domain model and do something useful at the same time?

How will we avoid imposing (the wrong) prescriptive model from the top down?

How will we keep it up to date and accurate?

We considered jumping straight into moving files around into a more modular structure. Ultimately we decided against this approach as a first step for a number of reasons. The benefit of moving files around is mostly abstract — it’s not immediately clear what to do with a better module structure. It’s relatively expensive to move files around in a Rails app — doing so typically requires you to rename the contents (and update all its callers), which amounts to a lot of busy work, and it’s extra expensive to be wrong. And the in-between state is rough: which example should I follow in deciding where to put my new file? First you are obligated to create a map of the future state, and then to keep that map in sync with reality as you go.

Instead, we opted for a lightweight solution that would allow us to map our domains and their owners in the code itself — helping to ensure it’s up to date and accurate — without having to restructure it at the same time. We’d do this by tagging code in code comments, and then building tools to leverage these tags in various ways to increase visibility and enforce ownership. This has the nice effect of producing a new domain map incrementally from the bottom up, rather than prescriptively from the top down.

We called this the '@owners' tag, and it looks like this:

# @owners { team: platform, domain: orders }
class Wunderbar::OrdersController < Wunderbar::WunderbarController
  def show
		...
  end

  # @owners { team: inventory }
  def out_of_stock
    ...
  end
end

We based our tooling around extending the YARD documentation tool to recognize this as a custom tag. You can teach YARD to recognize a custom tag by passing a command line option like '--tag owners:"Owners"', which by default will cause the tag value to appear in generated documentation under the header “Owners”. The Ruby API for declaring a tag programmatically is shown in the snippet below as well.

We wanted the tag to be interpreted hierarchically to handle cases where ownership has diverged within the same class or module, such that we might want to tag one or two methods differently from the rest, as well as to ease the burden when all of the classes / modules / methods under a namespace belong to the same team and domain, since you can just tag the shared parent. We set an initial goal around getting 100% of our methods covered by at least a “team” value, at which point we would require all code to be covered in our build process.

To get a basic feel for how to work with these tags, make sure the 'yard' gem is available, tag a couple of your files, and then try running the code below in your project. It will print out the tag associated with each tagged code block.

require 'yard'
# Define the custom tag.
YARD::Tags::Library.define_tag('Owners', :owners)

# Parse your codebase. You might want to pass a more specific path here.
YARD.parse('.')

# Load all the method, class and module code blocks into memory
code_blocks = YARD::Registry.all(:method, :class, :module)

# Print the tag associated with each tagged block.
code_blocks.each do |code_block|
  tag = code_block.tag('owners')
  # automatically tag nested classes, modules and methods.
  while tag.nil? && code_block.namespace != nil && [:class, :module].include?(code_block.namespace.type)
    code_block = code_block.namespace
    tag = code_block.tag('owners')
  end
  print "Code Block: #{code_block}, tag: #{tag.text}, line: #{tag.line}" if tag
end

We ultimately developed a handful of CLI tools based on this technique that allow us to produce reports measuring the percentage of code covered by team and domain at different levels, among other things:

bin/yardowners --help
Usage: bin/yardowners [options]
        --methods                    view by methods
        --files                      view by files
        --teams                      teams report
        --domains                    domains repot
        --team=TEAM                  filter by team
        --domain=DOMAIN              filter by domain
        --codeowners                 update codeowners
        --lint                       lint owners tags
        --require-domains            lint for presence of domain in  
owners tags
    -h, --help                       display this help and exit

We use this CLI to add checks to our CI process around coverage / correctness, as well as to report progress toward our goals of 100% coverage.

To get the tagging process started across the organization, we dumped all of our class and module names (thanks again, YARD!) into a big spreadsheet, and then asked each team to get together and spend a bit of time putting their names next to the ones they owned. We adopted the attitude that it was better to have the wrong value than no value, since it would be easy to adjust later.

We covered a good 80% of the code using this spreadsheet by the time each team had taken an initial pass. From there, we filled the blanks in with “TODO”, and then wrote a little script to automatically insert the tags into the code (again based on the YARD metadata, which conveniently gives you the line numbers for the top of each class / module declaration).

At that point, we enabled a linter requiring 100% team owner coverage on all new PRs. We set a new goal to eliminate TODOs, and chipped away at it over the course of a month or so. We then repeated this process for the “domain” values, driving that to 100% as well. We found that the spreadsheet-based divide-and-conquer approach allowed us to cover a lot of ground very quickly.

Once we were able to parse our '@owners' tags, the first and most important thing we did with them was to automatically generate our CODEOWNERS file. We enforce that each tagged team maps to a team name in github and check that CODEOWNERS is up to date during the build process. This new process introduced some friction, as teams started getting tagged every time a file they were tagged on changed. This turned out to be great, because it sparked a number of very productive negotiations around ownership and scope that got hashed out in code review. We keep our CODEOWNERS file synced with Sentry, too, so that exceptions raised by files you tagged as yours get assigned to your team automatically. We also track and report on the performance of individual endpoints by team according to how they are tagged.

The new owners tag hasn’t fixed all our problems by any means, but it has proved fundamental to our ability to operate as a growing set of increasingly independent teams with well specified responsibilities. In subsequent posts, we’ll talk more about how we’re using our new domain map and a suite of other cool tools to build better boundaries within and ultimately escape from our monolith.

Vaccines — which were first developed in 1796 for smallpox and continue to evolve with new research and technology — build on your immune system’s natural function to protect you from serious diseases. Just like white blood cells and the other components of your immune system, vaccines help you develop immunity, but without the initial illness and risk of health complications. Here’s a look at how vaccines work.

The Science Behind Vaccines

Your immune system has a natural way of defending you from the viruses and bacteria that cause illness. As these germs multiply rapidly and infect your body, an army of white blood cells fights back, producing antibodies that attack the invaders.

The first time you are infected by a specific virus or bacteria, your immune system often cannot destroy the germ quickly enough to prevent you from becoming sick. After you’ve recovered, certain immune cells hold onto the memory of the infection. This allows them to mobilize quickly if they encounter the same germ again, preventing illness in the future. Immunity, your body’s resistance to certain types of infection, is the outcome of this process.

To understand how vaccines work, it’s helpful to know how your immune system naturally fights an infection. B-lymphocyte white blood cells produce blood proteins called antibodies, which attack antigens — the part of the invading germ that triggers an immune response. T-lymphocyte white blood cells attack already infected cells in the body. After the infection has ended, a few T-lymphocytes, or memory cells, remain to ensure a fast immune response should the same germ reappear.

Vaccines imitate infections, triggering the process of building immunity to a specific disease without causing illness. Your immune system responds to these imitation infections the same way it would to an actual infection. Detecting antigens from the vaccine, your immune system produces antibodies and T-lymphocyte cells. The imitation infection leaves your body with T-lymphocyte memory cells and B-lymphocytes, which will know how to quickly fight that antigen in the future. This prevents you from becoming sick if you are exposed to the virus or bacteria that cause the disease.

It typically takes several weeks for your body to produce T-lymphocyte and B-lymphocyte cells in response to a vaccine, which is why in most cases you will not immediately develop immunity. This means that you could become infected with a disease and develop symptoms shortly after vaccination, so it’s important to take necessary precautions until you become fully immune to the virus or bacteria. The healthcare professional administering your vaccine will inform you of the anticipated timeline for immunity.

Sometimes the imitation infection created by a vaccine causes mild symptoms such as a fever. These side effects are normal and indicate that your body is building immunity.

While all vaccines arrive at the end result of immunity, there are several paths for getting there. When deciding which type of vaccine to create for a disease, researchers consider a variety of factors, including the immune system’s response to the germ that causes the disease, the population likely to receive the vaccine, and the regions of the world where it will be used. These are the seven types of vaccines commonly used in the U.S.

Live vaccines use a weakened version of the living virus or bacteria that causes a disease. They are most similar to the natural infection and produce long-lasting immunity. The weakened form of the germ does not lead to serious disease, like that caused by the wild form of the germ, for most individuals with strong immune systems. However, live vaccines aren’t safe for those who are immunocompromised, including children undergoing cancer treatment. Examples of live vaccines include the measles, mumps, and rubella (MMR) vaccine and the chickenpox vaccine.

Inactivated vaccines are produced by inactivating, or killing, the germ that causes a disease. Examples include the polio, hepatitis A, and flu vaccines. They don’t provide as strong of immunity as live vaccines, so additional doses, also referred to as booster shots, are often needed for ongoing protection.

Toxoid vaccines target a toxin, a harmful substance produced by a germ, rather than the entire germ itself. They contain a weakened version of the toxin to be targeted called a toxoid, which teaches your immune system how to fight off the natural toxin. Similar to the germs used in live vaccines, toxoids are weakened to a point where they do not cause illness. These vaccines are used to prevent diseases caused by toxin-producing bacteria such as diphtheria and tetanus.

Subunit vaccines use portions of a virus or bacteria called subunits rather than the entire germ. Vaccines for diphtheria, tetanus, and pertussis, or whooping cough, are combined into the DTaP vaccine. The pertussis component is a subunit vaccine.

Conjugate vaccines fight a specific type of bacteria whose antigens are more difficult for a child’s immune system to detect due to their outer coating. The vaccines link the coating to stronger antigens that the immune system can more easily respond to. Like subunit vaccines, these vaccines are more targeted and only use part of the germ. Examples of conjugate vaccines include the haemophilus influenzae type B (Hib) vaccine.

Viral vector vaccines produce immunity to a virus by using a modified version of a different virus to deliver instructions to your immune cells. The modified version of the other virus is referred to as a vector virus. Recent Ebola vaccines have used this technology, and the Johnson & Johnson COVID-19 vaccine is also a viral vector vaccine.

mRNA vaccines help your body produce a protein that triggers an immune response and the development of antibodies. This technology was used to create the Pfizer-BioNTech and Moderna COVID-19 vaccines.

Read ‘What the COVID-19 Vaccine Means for Those With HIV’

All vaccines in the United States require approval by the Food and Drug Administration (FDA) and are held to rigorous safety and effectiveness standards. The vaccine approval process starts with lab tests, which may take years in some cases. The FDA analyzes the results to determine if the vaccine should be tested with people. If the vaccine moves forward, the next step is clinical trials where the vaccine is tested on volunteers.

Clinical trials typically begin with a smaller group of 20 to 100 volunteers before including thousands more. The trials gather information about vaccine safety, the typical immune response, and dosing. If any safety concerns emerge during this stage, the FDA must address them before it can authorize the vaccine.

Vaccine manufacturers are required to continuously monitor vaccine safety after approval and test every batch produced to ensure effectiveness, quality, and purity. These test results are reviewed by the FDA, which also conducts an inspection of the factory where the vaccine was produced. If you experience severe side effects after vaccination, contact your healthcare provider so that they can report potential concerns to the Centers for Disease Control and Prevention (CDC)’s vaccine monitoring database.

COVID-19 mRNA vaccines were developed and approved more quickly than a typical vaccine given the urgent nature of the pandemic. This expedited timeline was made possible by significant investment from governments and companies in the vaccine development process and decades of research on mRNA vaccine technology. These vaccines were as thoroughly vetted for quality and safety as any other vaccine.

Many vaccines are received during childhood, like the polio, chickenpox, and MMR vaccines, but there are others you may need as an adult. The CDC recommends the zoster vaccine, which prevents shingles, for adults ages 50 and older and the pneumonia vaccine for those over 65. Other vaccines may be recommended based on additional factors including job or school requirements, travel, and health conditions. Check in with your doctor about which vaccines you need.

The CDC also recommends an annual flu vaccine for everyone 6 months and older. New versions of flu vaccines are developed annually in anticipation of circulating flu virus strains, so health experts recommend getting one every year to prepare for cold and flu season. It’s especially important to be proactive about flu vaccination if you are over the age of 65 or have a chronic condition such as COPD or diabetes.

For detailed vaccine recommendations by age group, reference the CDC’s recommended immunization schedules for children and adolescents and adults.

At Alto, a pharmacist is your partner in health. If you take medication, we will work with your doctor, your insurance (if applicable), and any third party savings programs that you may qualify for to make your medications as affordable as possible. And our team of pharmacists is available to chat whenever questions come up. 

Reach out any time through in-app secure messaging or by phone at 1-800-874-5881.

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. 

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.

Blog

Get to know Jake Moffatt, Engineering Manager on the Alto Assistant Team

Introducing Alto’s New CEO - Alicia Boler Davis

Infertility, Explained

Alto Pharmacy Announced as One of Forbes Best Startup Employers for the Second Consecutive Year!

Two Engineering Interns Weigh In: What to Expect From Your Alto Internship

How We Established Better Boundaries and Clearer Code Ownership at Alto

The Science Behind Vaccines

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

Developing Robust Authentication Using Rails, Omniauth, and Okta

Considerations and Approaches for Implementing Biometric Login: Part 1

Top Questions to Ask Your Fertility Clinic

Meet Ramiah Martin, VP, Operations & Supply Chain

Switch to a better pharmacy.