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.

Face and fingerprint ID login is a convenient, seamless way to gain app access on a mobile device. Instead of typing in a lengthy, hard-to-remember username and password, many apps allow you login with just a quick scan of your face or fingerprint (also known as biometrics).

Considerations and Approaches for Implementing Biometric Login: Part 1

It's a desirable feature for both our end user and the Patients Team here at Alto — we want to make it as easy as possible for users to log in while also performing more frequent authentication checks. Improve the user experience and the security of our app? Sounds like a win-win.

As an engineer, implementing biometric login might seem easy, as mobile devices already capture, manage, and encrypt biometric data and expose APIs for app developers like myself to initiate a biometric scan. All I need to do is call that API and wait to hear if the scan is successful or not. What isn't as simple, though, is figuring out what to actually do with a successful biometric scan response. What does a successful scan mean, and how does that relate to the username and password credentials that users currently use to access our app?

This post walks through the decision points we encountered while implementing biometric login and how our healthcare privacy concerns influenced the final implementation approach.

Prior to implementing biometric login, the only way for users to access the Alto app was with email (username) and password. A valid email and password generates a session, which expires at some frequency. Once the session expires, the user must re-enter their email and password to regain access to the app.

From the beginning, we knew that biometrics would need to be built with our existing email and password session management in mind. This is made clear in the Apple developer docs: "Use biometrics as a supplement to something you’re already doing. Don’t depend on biometrics as your only authentication option."

Make it easier for users to login. Nobody likes typing in an email and password — especially on a mobile app. Our goal was to reduce the number of times a user must enter their email and password.

Enhance the security of our app using more frequent authentication checks. As a healthcare app that displays Personal Health Information (PHI), conducting more frequent authorization checks decreases the likelihood of PHI becoming exposed to an unauthorized third party.

Have the ability to revoke biometric access from a particular user. Similarly, we want to be extra careful to ensure that if a device is lost or stolen, we have a fallback plan to invalidate a user's session and protect the user’s PHI. For email and password initiated sessions, this happens when a user changes their password, as any change in login credentials will invalidate all active sessions for that user. We needed a similar contingency plan for biometric login.

There are several ways to use a mobile device's biometrics to authenticate a user, with varying degrees of security.

No server-side authentication. Simply integrate with the device's biometrics as an extra layer of authentication. If the biometric scan is successful, let the user proceed into the app.

Provides an extra check and gives your app a sense of modern polish

No server-side validation means that nothing is being validated against your system, so this is not a good substitute for account authentication. Therefore, even if you add this check, the user should still be prompted to re-enter their email and password at the same frequency as before.

Given this, this approach wouldn't help us reach our goal of reducing the number of times a user must enter their email and password.

This approach is a good fit if your application already has an existing login and session management system, and you want extra authentication checks throughout the user's session without modifying any other part of the system.

Tie biometrics to our existing email and password authentication. Use the user's biometrics to unlock an encrypted version of their email and password credentials. When a user sets up biometric login, store the user's login credentials within the device's keystore — the keystore will automatically encrypt the credentials. After a successful biometric scan, retrieve those credentials from the keystore and send them to your existing login API.

Still easy to implement, no backend changes needed

Biometric scan can be used in place of entering an email and password

Changing email and password credentials will revoke biometric access: if a user changes their credentials, their biometrics will access stale credentials and fail to login. (This is somewhat of a con as well — it provides a poor user experience, but it's an edge case that should happen infrequently.)

There is still only one way for a user to authenticate server-side, but now two ways to pass server-side authentication — essentially weakening your app's existing account security.

This approach effectively hands out internal login credentials to third party storage. While not a huge risk considering a device's secure storage is encrypted and trusted by most users, it’s not necessarily a best practice either.

This approach is a good fit if your application doesn't contain sensitive data, and your goal is to make it more convenient for a user to login by replacing email and password with a biometric scan.

Create a separate authentication mechanism for biometrics. Introduce a new authentication mechanism specifically for biometrics, resulting in two independent forms of server-side session authentication: email with password and biometrics. The implementation could look like generating a keypair or a shared secret to save and validate against the server whenever a user attempts to login with biometrics.

Biometrics is now tied to its own secure server-side authentication mechanism, which means it can be used independently of email/password (or even replace it, if you choose to).

Two layers of authentication adds security to the app. Not only does a user need a valid email/password session, they also need a valid biometric session.

It provides fine-grain control over a user's biometric session. You can invalidate a user's biometric session by invalidating the public key and can even invalidate a biometric session without impacting an email-and-password session if needed.

Requires building and maintaining a separate authentication mechanism

This approach is a good fit if your application contains sensitive data (e.g. PHI or financial information), and your goals are to make it both more convenient for a user to login by replacing email and password with a biometric scan while also strengthening the security of your account management system.

Because we are a healthcare company dealing with sensitive data, we chose this last path. It required greater engineering investment, but we agreed it was imperative that we maintain a secure system while introducing biometric login for users.

In part 2, we talk implementation details, including the library we used, code snippets, and questions to consider before you get started. Interested in learning more about engineering at Alto? Follow us on LinkedIn.

There’s a lot to cover during a consultation, so you may find it helpful to prepare a list of questions in advance. Our fertility pharmacy experts offer some suggestions to get you started below.

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.

We’re excited to welcome Christopher Tidball to the Alto team as Director of Product Management, Supply Chain & Fulfillment. Learn more about his passions both in and outside of work and what drew him to Alto.

Introducing Christopher Tidball, Director of Product Management - Supply Chain & Fulfillment

We’re excited to welcome Christopher Tidball to the Alto team as Director of Product Management, Supply Chain & Fulfillment. Most recently, Christopher led a large team of product managers, engineers and program managers at Amazon to power the company’s most complex fulfillment operations. 

As Alto continues to expand our geographic footprint and customer base, Christopher’s nearly 20 years of industry experience will support us in scaling our systems, so that we can continue to deliver the same high standards of care and service to even more communities.

We recently sat down with Christopher to learn more about his passions both in and outside of work, what drew him to Alto, and the operational opportunities he’s most excited about. 

Before a recruiter ever reached out to me about a role at Alto, my wife and I were very satisfied customers. We had been on a long journey of trying to start a family, and that ultimately led us to a fertility clinic that recommended Alto. We had a great experience from day one: the app was easy to use, the same-day deliveries from couriers were always on time, and Alto’s pharmacists walked us through the various medications in our delivery and answered all of our questions. 

Alto’s focus on the customer experience was immediately clear, and I made a mental note that this was the type of company I’d like to work for. Fast forward a few months later, a recruiter reached out and introduced me to the leadership team whose passion and experience sold me on leaving Amazon to come here.

As the Director of Product Management - Supply Chain and Fulfillment, I'll focus on the technology investments that can help us continue to grow and offer exceptional service to our customers. “Supply chain” covers a lot of ground: procurement, inventory, pharmacy operations, delivery, and more. There are tons of opportunities to automate processes to make it easier for Altoids to run the business, especially as we grow and expand. 

What areas of the business are you most excited about?

The operations side has always been exciting to me—it's where the magic happens. At the end of the day, if we don't have sustainable, efficient ways to fulfill the promises we make to our customers, we won't survive. 

Alto has a great business model, and many happy customers to show for it, but there’s always room to continue to innovate and improve the delivery experience. It's one of the few in-person interactions we have with the customer and we want to make it exceptional.

Tell us about life outside of Alto. Are you doing anything interesting at the moment?

I'm a pilot in training — I'm about 75% of the way to getting my single-engine license. I live in Seattle so the aerial views of the city, Puget Sound, and the Cascade Mountains are absolutely breathtaking. Flying gives you a sense of freedom that reminds me of when I first got my driver's license.

You can find more information about Christopher 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.

Infertility is often thought of as exclusively a women’s health issue, but the truth is that it can affect anyone regardless of gender. We explain more including male infertility causes, symptoms, and treatment options.

Male Infertility: Causes, Symptoms, and Treatment

Infertility is often thought of as exclusively a women’s health issue, but the truth is that it can affect anyone regardless of gender. About one-third of infertility cases include factors related to male reproductive function.

If you’ve experienced infertility, you’re not alone: about 9% of men and about 11% of women in the U.S. have experienced fertility challenges. And while these challenges may feel overwhelming, they do not necessarily mean that you won’t be able to start a family one day — there are a variety of fertility treatment options for both men and women to support your family building journey.

Below, we explain more about male infertility, including causes, symptoms, and treatment options that can help you build or add to your family.

Male infertility most often stems from issues with sperm production. In some cases, it may be a problem with the quality of your sperm, like how fast or how well your sperm move. In other instances, it’s a matter of sperm quantity: you may not be able to produce any sperm, or you may have a low sperm count (the threshold is typically a sperm count under 15 million sperm per milliliter of semen.)

Sperm production problems may also occur as the result of other health conditions, including hormone, pituitary gland, or immune system problems or genetic conditions like cystic fibrosis, a progressive disease that makes it difficult to breathe, and hemochromatosis, a condition in which you have an excess of iron in your system.

Lifestyle and environmental factors can also play a role: heavy smoking (20 or more cigarettes per day), consistent heavy drinking or binge drinking (for men, five or more drinks in a two-hour timeframe), drug use, and exposure to toxins like endocrine disruptors contained in plastics and pesticides have been linked to male infertility.

Beyond issues with sperm production, anything that blocks a reproductive organ can interfere with the flow of semen, including inflammation from a sexually transmitted infection, scar tissue from surgery, or swollen veins in any of your reproductive organs. Additional factors in male infertility include erectile dysfunction, premature ejaculation, liver or kidney disease, and treatment for seizure disorders.

You may have a greater chance of experiencing fertility issues if you have had any of the following:

Inflammation of your prostate or genital infections

Certain prescription medications may also increase your risk of infertility, including:

5-alpha-reductase inhibitors, a medication class used to treat prostate enlargement and hair loss, which includes finasteride (Propecia®) and dutasteride (Avodart®)

Alpha blockers like silodosin (Rapaflo®), tamsulosin (Flomax®), alfuzosin (Uroxatral®), terazosin (Hytrin®), doxazosin (Cardura®), which are used to treat prostate enlargement

Blog

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

Introducing Christopher Tidball, Director of Product Management - Supply Chain & Fulfillment

Male Infertility: Causes, Symptoms, and Treatment

The Role of Insulin Pumps in Diabetes Treatment

What to know about RESOLVE: The National Infertility Association

Get to Know the Team That Has Doctors Calling Alto “The Pharmacy of The Future”

Spotlight on Men Having Babies & Dr. Guy Ringler

What to Know About Dry Powder Inhalers

Switch to a better pharmacy.