Shop Alto Essentials to add pharmacy products to any 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

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.

Inhalers and nebulizers are both effective at delivering medications for respiratory conditions like asthma and chronic obstructive pulmonary disease (COPD). A nebulizer is a device that transforms a liquid medication into a fine mist which is then inhaled into the lungs through a mouthpiece. While nebulizers take longer to deliver medications than inhalers, their accurate dosage delivery is often a good fit for children living with asthma and other lung diseases, and many adults find them helpful as well. Here’s what to know if you’re considering using a nebulizer.

What to Know About Nebulizers

Three types of nebulizers can be used to treat asthma, COPD, and other lung diseases like pulmonary fibrosis.

Jet nebulizers transform liquid medication into an aerosol or fine mist using an air compressor. They are the most common type of nebulizer.

Mesh nebulizers use a fine mesh to create an aerosol from the liquid medication. They are the newest type of nebulizer and emit the smallest particles.

Ultrasonic nebulizers create an aerosol through high-frequency vibrations. They are typically used in hospitals or at doctors’ offices.

There are different models of nebulizers, including portable, battery-run nebulizers that can be taken with you on the go and larger tabletop nebulizers that require an electrical outlet. These devices can deliver a variety of medications, including quick-relief medications that treat acute symptoms of lung diseases as well as longer-term maintenance medications. They may even be used to deliver more than one medication at once.

Your healthcare provider can advise you on the best method of medication delivery for your individual treatment plan. As you explore your options, be mindful of the key differences between nebulizers and inhalers.

Inhalers deliver medication quickly, but they require enough coordination to inhale and spray the medication at the same time. Some individuals, particularly young children, may find it challenging to properly use an inhaler. This can result in not receiving the full dose of medication.

To receive a dose of medication from a nebulizer, all that’s required is to breathe normally. However, nebulizers will take at least five to ten minutes to fully deliver the medication. You may want to ask your doctor which type of device they recommend for treating acute symptoms during an asthma attack or COPD flare-up.

If you and your doctor have decided that a nebulizer is a good fit for your needs, learning about proper use and cleaning of the device is a key part of managing your health. It will also ensure that you are taking your medication as prescribed. Be sure to follow your doctor’s instructions and review the manufacturer’s instructions for your nebulizer before using it for the first time, as there is some variation among these devices.

All nebulizers have a medicine cup, a mask and/or mouthpiece, an air compressor, and plastic tubing to connect the compressor to the medicine cup. Always wash and dry your hands before using your nebulizer and make sure that all the pieces of your nebulizer are clean. Pour the correct dose of your medication into the medicine cup and connect the tubing to the air compressor and medicine cup. Turn on your nebulizer and ensure that it’s properly working. You should see a fine mist coming from the mask or mouthpiece.

Once you see a mist appear, your nebulizer is ready for use. To inhale your medication, secure the mask over your nose and mouth or put the mouthpiece in your mouth. Sit upright and breathe normally. Taking slower breaths can help the medication enter your airways. Continue to breathe normally until the medication is gone from the cup.

Bacteria and other germs can grow inside of a nebulizer that has not been properly cleaned, so it’s important to clean your device after every use and disinfect it once a week.

After you’ve finished using your nebulizer, wash the mouthpiece or mask and the medicine cup in warm soapy water and let them air dry. For weekly disinfecting, soak these pieces in a vinegar solution for 30 to 60 minutes, or for the amount of time specified by your doctor or in the manufacturer’s instructions. Your doctor may provide you with a disinfectant solution, but if not, you can mix one part white vinegar with three parts hot water. After the pieces are done soaking, let them air dry. Put these pieces in a plastic container or bag and store it in a cool, dry place.

As part of nebulizer maintenance, you should replace the plastic tubing on a regular basis. Ask your healthcare provider how often to replace the tubing.

When deciding whether a nebulizer is a good fit for your needs, be sure to consider your health insurance benefits. Most insurance plans have separate medical and pharmacy benefits in addition to a Durable Medical Equipment (DME) section. Many nebulizers fall under the DME category of your policy. There may be restrictions on the brands, suppliers, or types of nebulizers that are available, and it’s important to check with your specific policy to understand what will be covered and under which sections.

Alto makes it easy to stay on top of your asthma or COPD treatment, with free hand-delivery, automatic savings investigations, and easy medication management tools through our website and app. And our team of pharmacists is always here to answer your questions by phone or chat. 

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

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.

Inhalers and nebulizers are both effective at delivering medications for respiratory conditions like asthma and chronic obstructive pulmonary disease (COPD).

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.

Whether traveling domestically or abroad, arriving at your destination with the medication you need is rarely as simple as packing it in your suitcase. From TSA compliance to temperature control, there are many factors to consider when traveling with medication — not to mention getting enough of a supply for the whole trip (plus extra, just in case).

Managing Your Medications While Traveling | Alto Pharmacy

Planning is key to managing your prescriptions and staying on top of your health needs while you’re away from home. Follow these tips to prepare for your next trip.

Research your destination’s medication laws

Many medications that are legal in the U.S. aren’t allowed in other countries. And it’s not only prescription medications: even over-the-counter treatment options may not be permitted in some destinations.

To avoid any unwelcome surprises while going through customs — or any missed doses — confirm that your medications are legal in the country you’re visiting. As a starting point, check with that country’s U.S. embassy. Consider that some countries may only allow a 30-day supply for certain medications and/or require you to carry an official prescription or additional information from your doctor with you. If you learn that your medication is not allowed at your destination, contact your healthcare provider to discuss your options.

There are legal considerations to be aware of even if you are traveling within the U.S. For example, you may be able to fill certain prescriptions out of state if you lose your medication or forget to order a refill before your trip, but the laws vary by state and there are often restrictions on controlled substances. Do your research in advance and make sure to prepare for any scenario.

Make sure you have enough of your medication

Unforeseen changes can happen when traveling, so it’s important to have more than enough medication on hand. Aim for an additional week or two’s supply. Allow yourself plenty of time to fill your prescription(s) before your trip. Depending on when you are due for a refill, you may need to request an early refill authorization from your insurance company — sometimes referred to as a vacation override — in order to get your medication in advance. (Alto can help with this!) 

In addition, make sure you’re prepared in the event that you misplace your medication during your trip. Write down the generic names of your medications, which may be more commonly available at pharmacies in other countries.

Lost luggage can be more than an inconvenience if your medication is in your checked bag, so always pack any important medications in your carry-on. This does mean you’ll have to be mindful of security requirements, particularly if carrying liquid medication. The U.S. Transportation Security Administration (TSA)’s current limit on liquids, gels, and creams in a carry-on bag is 3.4 ounces (100 milliliters), but there are exceptions for liquid medications. For the easiest travel experience, inform the TSA officer that you are carrying more than 3.4 ounces of liquid medication before your screening process begins, and be aware that additional screening of your medication may be required.

Keep your medications in their original packaging to avoid any issues when passing through security or customs. You may want to bring an official prescription or other documentation of your medical condition as an additional precaution, especially if you take a controlled substance or are traveling abroad.

Many medications lose their effectiveness if held at extreme temperatures, which is another reason to put your medication in your carry-on, as a plane’s luggage compartment can be very cold. If you take a medication that requires refrigeration like insulin, make sure you have what you need to hold your medication at an appropriate temperature.

Many people with diabetes use insulated medication bags to refrigerate insulin when traveling. Read ‘How to Prepare a Diabetes Emergency Kit’ for more information on the diabetes essentials to bring on a trip.

If you’re traveling far from home, anticipate how time zone changes may impact your medication schedule. Before your trip, ask your doctor how to handle the time zone shift and what to do if you accidentally miss a dose — some medications have more flexible timing of doses than others. 

Getting a last-minute refill before a trip is low stress with a flexible pharmacy partner like Alto. We offer free same-day delivery seven days a week, with the convenience of choosing the best delivery window for your schedule. And we’ll work with your doctor, your insurance (if applicable), and any third party savings programs that you may qualify for to ensure your medications are as affordable as possible

Managing Your Medications While Traveling

Overall heart health involves all the components of this complex network. Coronary artery disease — the most common type of heart disease — affects your blood vessels and the flow of blood to your heart. It typically develops over the course of many years, and many of the key risk factors can be managed. Here’s what to know about preventing and treating this type of heart disease.

Coronary Artery Disease, Explained

Your heart is at work every minute of the day, pumping blood to deliver oxygen to vital organs. Each part of the heart plays a role in this important task, along with the rest of your cardiovascular system, including your arteries and blood vessels.

Like any organ in your body, your heart needs oxygen to function. Coronary arteries are the blood vessels that supply your heart with oxygen-rich blood. Coronary artery disease occurs when these blood vessels are hardened or blocked, affecting the flow of blood to the heart itself.

This condition is often caused by atherosclerosis — the accumulation of substances like cholesterol and blood-clotting material in your arteries. (These substances are collectively referred to as plaque). A variety of factors can increase your risk for atherosclerosis — and therefore your risk for heart disease — including high LDL cholesterol, high blood pressure, diabetes, obesity, physical inactivity, and smoking. Additional key risk factors for heart disease include age and family history. 

There are several known symptoms of coronary artery disease, including chest pain or tightness (also called angina) and shortness of breath. Depending on where your blood vessels have narrowed, you may also experience pain, numbness, or weakness in your arms or legs. Women are more likely than men to experience additional symptoms such as nausea, back and jaw pain, and shortness of breath without accompanying chest pain.

Symptoms of coronary artery disease present differently from one person to another. It is best to discuss your risk of heart disease with your doctor if you have concerns rather than waiting for symptoms to appear. It’s especially important to be proactive if you have a family history of heart disease.

In the long term, coronary artery disease can increase your risk for other heart health issues, including heart attack and heart failure, which occurs when your heart cannot pump all of the blood that your body needs. These serious health risks are preventable — by identifying coronary artery disease at an early stage and following the treatment plan your doctor recommends, you can manage the condition and lower your risk for related complications.

Too often, people learn that they have coronary artery disease only after experiencing a more serious complication like a heart attack, stroke, or heart failure. Consulting with your doctor about your risk for heart disease and staying up to date with blood pressure, cholesterol, and blood glucose screenings is key to detecting heart health problems early on. Here are some of the numbers your doctor will track to identify your risk for heart disease, along with your individual and family health history.

The National Institutes of Health defines normal blood pressure for most adults as below 120 mm Hg systolic and 80 mm Hg diastolic. (Systolic pressure, the first number in your blood pressure reading, is typically the reading that’s most important when monitoring blood pressure.) If your blood pressure falls in this range, typical screening frequency is at least once per year. If your blood pressure is in a higher range, ask your doctor about recommended screening frequency.

Your cholesterol levels can also help your healthcare provider identify your risk for heart health issues. If your total cholesterol is under 200 mg/dL, you can have your cholesterol checked every 4-6 years. If you are at higher risk for heart disease and stroke, consult your doctor about recommended screening frequency.

In the long term, high blood sugar can damage your blood vessels, and diabetes is a risk factor for coronary artery disease. It’s important to monitor your blood glucose levels as part of your broader heart disease prevention efforts, especially once you enter your 50s and 60s. Your doctor can advise you on recommended screening frequency.

Remember that it’s never too early or too late to prioritize heart-healthy living. Read our previous blog, ‘How to Prevent Heart Disease at Any Age’ to learn about important heart disease prevention actions for your age group.

If you have coronary artery disease, your doctor may recommend lifestyle changes and/or medications to manage your heart disease risk factors. Quitting smoking, planning a heart-healthy diet, and exercising more frequently are often a first step in managing coronary artery disease.

The specific medications used to treat coronary artery disease vary by individual. Your doctor may prescribe one or more of the following types of medications depending on your health history:

Cholesterol-lowering medications like statins, fibrates, and niacin

Blood pressure medications like beta blockers, calcium channel blockers, and ACE inhibitors

Anticoagulants and antiplatelets to reduce your risk of blood clots

Heart-healthy living is a lifelong practice, and heart disease prevention or treatment is an ongoing commitment to your health. At Alto, we make it as simple as possible to manage your risk for heart health issues like coronary artery disease and stay on top of cholesterol-lowering or blood pressure management medications. 

We will work with your doctor, your insurance (if applicable), and any third party savings programs that you may qualify for to ensure your medications are as affordable as possible. And our team of pharmacists is available to chat whenever questions come up about side effects or how to take your medication properly.

When inflammation persists, it no longer serves a helpful purpose. This type of inflammation, also referred to as chronic inflammation, occurs when your body consistently acts like it’s under attack, releasing white blood cells indefinitely. In the long term, an elevated white blood cell count can affect other organs such as your heart, lungs, and kidneys. Research has also found a connection between chronic inflammation and other chronic diseases including heart disease, diabetes, cancer, Alzheimer’s disease and Crohn’s disease.

Inflammation, Explained

Acute inflammation is the body’s natural way of fighting infections and injuries as part of the healing process. When you have an injury, blood flow increases as your body instinctively releases white blood cells, proteins, and other inflammatory chemicals to protect the wounded area. This leads to redness, swelling, and pain at the site of injury. The body reacts similarly when you have a virus or cold, but in these instances, the blood cells and inflammatory chemicals are released throughout the whole body rather than to one spot. This type of inflammation is good for you, as it allows your body to heal.

But when inflammation persists, it no longer serves a helpful purpose. This type of inflammation, also referred to as chronic inflammation, occurs when your body consistently acts like it’s under attack, releasing white blood cells indefinitely. In the long term, an elevated white blood cell count can affect other organs such as your heart, lungs, and kidneys. Research has also found a connection between chronic inflammation and other chronic diseases including heart disease, diabetes, cancer, Alzheimer’s disease and Crohn’s disease.

Read on for more information about the causes and symptoms of chronic inflammation and how to prevent or treat it.

Causes and symptoms of chronic inflammation

Several known factors can trigger chronic inflammation:

Lifestyle factors including obesity, diet, smoking, alcohol use, stress, and sleep disorders

Autoimmune diseases like type 1 diabetes or lupus, in which the body mistakenly attacks itself

Long-term exposure to pollution, industrial chemicals, or other toxins

Some individuals with this type of inflammation experience fatigue, fever, and joint and muscle pain. However, while there are clear physical signs of acute inflammation, chronic inflammation does not always have visible symptoms.

Your doctor can help determine if you have chronic inflammation. They will likely ask about your symptoms and perform a physical exam as a first step. They may then order additional tests to detect inflammation. These tests look for various indications of inflammation in your body, but they cannot formally diagnose inflammation or any other health condition. Rather, they provide a more comprehensive picture of your health so that your doctor can recommend the best next steps.

Potential tests your doctor may recommend during this process include a C-reactive protein (CRP) test and/or an erythrocyte sedimentation rate (ESR) test. A CRP test identifies your blood levels of CRP, a protein produced in your liver. Chronic and acute inflammation have both been linked to high levels of CRP.

An ESR test examines how quickly your red blood cells sink to the bottom of a test tube, with higher rates of settlement pointing toward more inflammation. Doctors often recommend this test when there is a possibility of high inflammation.

Sometimes these tests may help your doctor diagnose an inflammation-linked condition, such as rheumatoid arthritis or type 2 diabetes.

Chronic inflammation and other health conditions

There is a connection between chronic inflammation and many other health conditions. Inflammation can occur directly as the result of rheumatoid arthritis, which is both an autoimmune condition and an inflammatory disease. If you have rheumatoid arthritis, your immune system attacks your joints — often in your hands, writs, and knees — which leads to inflammation. There is also a direct link between inflammation and other inflammatory diseases, like ulcerative colitis and Crohn’s disease.

Inflammation has also been linked to heart disease and diabetes, but research into this connection is ongoing. While inflammation is more common in individuals with these health conditions, there is not yet definitive evidence that inflammation by itself directly increases your risk for these conditions.

Inflammation in the walls of your blood vessels has been linked to atherosclerosis, the accumulation of fats, cholesterol, and other substances in your arteries. In the long term, atherosclerosis increases your risk for a heart attack or stroke.

Since obesity, smoking, and physical activity are all risk factors for inflammation, heart disease, and diabetes, the overlap of these risk factors likely plays a role in the connection between the conditions. The good news is that a single healthy choice can lower your risk for all three diseases at once.

Your healthcare provider will recommend treatment based on the type of inflammation you have, however not all cases of chronic inflammation require medication.

Two types of medications are commonly used to lower both acute and chronic inflammation: nonsteroidal anti-inflammatory drugs (NSAIDs) including ibuprofen (Advil®), aspirin (Bayer®) or naproxen (Aleve®) and oral steroids including prednisone (Deltasone®, Prednicot®), methylprednisolone (Medrol®), and dexamethasone (Decadron®, Dexasone®). Steroid injections can reduce inflammation in a specific joint or muscle and are often used to treat rheumatoid arthritis.

If you have an inflammatory disease, your doctor may recommend medications specifically used to treat that disease. Medication classes commonly used to treat inflammatory diseases include:

Disease-modifying anti-rheumatic drugs (DMARDs) like methotrexate (Rheumatrex®), sulfasalazine (Azulfidine®), and leflunomide (Arava®). These medications can slow the progression of rheumatoid arthritis.

Statins, a type of medication commonly used to treat high cholesterol. They have anti-inflammatory effects and can lower CRP levels.

You can also fight inflammation simply by what you eat. An anti-inflammatory diet includes antioxidant-rich foods like the following: 

Cherries, blueberries, oranges, and other fruits

There are also some foods that have been linked to higher levels of inflammation. If you have chronic inflammation, your doctor may suggest limiting your intake of the foods below as part of your treatment plan:

White bread, pasta, pastries, and other refined carbohydrates

Soda, fruit juices with added sugar, energy drinks, and other beverages high in sugar

Red meat and processed meat like hot dogs and sausage

At Alto, we’re committed to making it as simple as possible to prioritize your health and well-being and stay on top of your medications.  We will work with your doctor, your insurance (if applicable), and any third party savings programs that you may qualify for to ensure your medications are as affordable as possible. And our team of pharmacists is available to chat whenever questions come up about side effects or how to take your medication properly.

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.

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!

Blog

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

What to Know About Nebulizers

Developing Robust Authentication Using Rails, Omniauth, and Okta

Managing Your Medications While Traveling

Coronary Artery Disease, Explained

Inflammation, Explained

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

What To Know About Insulin Pens

Emphysema: Causes, Symptoms and Treatments

Hello Austin, We're Alto Pharmacy!

All About HIV: Stages, Symptoms and Treatment

How to Take Action for World AIDS Day 2021

Switch to a better pharmacy.