The Toxicology Journey of Bicycle Health

Introduction & Background

Drug testing is an essential component of treating opioid use disorder. It is an objective way to show progress toward goals, maintain patient accountability, prevent diversion, and ensure safety of treatment.  In order to be truly effective, drug testing needs to be randomly implemented over the course of a treatment regimen; doing so precludes the possibility of a sample substitution that can arise from advance notice.

In a traditional Office Based Opioid Treatment (OBOT) program, patients are prompted to complete a test at random via phone, SMS, or email; they then complete the test at the OBOT facility or a nearby LabCorp or Quest. However, for a digital clinic like Bicycle Health, where our promise to patients is built around confidential, affordable care from the treatment of one’s home, random drug screening presents a significant caveat. Our drug screening protocol is one that is also often called into question given that we operate in a fully remote capacity; ensuring that our drug screening protocol meets (and ideally, exceeds) the rigor of that employed by a traditional OBOT is also an immense challenge.

From our onset, for the vast majority of our patients, drug screening has involved (a) receiving at-home test kits via mail (b) being prompted by Bicycle Health staff to complete a drug test at the medical providers’ direction and (c) uploading images of those at-home tests in our mobile application. Each of these steps presents different clinical, operational, and technological challenges, all of which have evolved considerably since the founding of the company.

This year, we were proud to launch our latest iteration of our toxicology process: a culmination of months of effort dedicated to establishing a warehousing operation capable of reliably shipping supplies in under a week to patients across the entire country, developing a technology stack capable of interfacing with our EMR to automatically ship and track kits, and a clinical protocol designed to promote compliance towards random screening. We wanted to share what we learned across all three of these fronts in the following blog posting.

Operations: From a garage to a national warehouse

Like any good startup story, the journey of our toxicology process started in a garage. As the Covid-19 pandemic set in, we quickly needed to adapt our in-person treatment protocols to support a fully remote model. Overnight, we stopped seeing patients in-person for their first appointment, when they would complete their first drug screen. We also stopped sending patients to labs, like Quest or LabCorp, for their follow-up toxicology tests due to Covid-19 transmission risk.

In an effort to prioritize the health and safety of our patients and teammates, and also maintain our standard of care, we started shipping toxicology tests directly to our patients’ homes. We hired a teammate to help support this effort, storing and shipping our toxicology kits from his garage. 

But, the operational changes needed to support this effort didn’t stop there. We worked with our enrollment team to add questions to our intake process to capture the patient’s home address and get their consent to ship directly to them. We trained our internal support staff to help upload toxicology results, re-order supplies, and communicate policies to patients when needed. As the service expanded, we turned these packages into welcome kits for our patients. 

We quickly outgrew this solution. Ordering supplies in small batches and manually packing and tracking shipments coupled with our growth nationally made this solution unsustainable from a cost and efficiency perspective. Bicycle Health’s mission is to provide low-cost and accessible treatment for patients – high cost of low batch orders and labor and delayed shipments from shipping vendors were early indicators that we needed to make a change.

Our first step was partnering with our product team. We built a pilot platform to automate our manual tracking and ordering. As we saw substantial gains in efficiency, we then looked into the distribution side. We interviewed 4 distributors across the country to understand sourcing and the cost of buying our toxicology products in bulk, with an acute focus on picking a partner that would maintain high-quality standards and allow us to customize our orders in the future. We then interviewed warehousing platforms that would help us to store, pack, and distribute our toxicology kits. Once we found our partner to support our scale and internal controls, we started the process of leveraging technology to support our operations.

Technology: APIs on top of APIs (all on top of an EMR)

The set of requirements for a fully automated toxicology system is quite daunting for a young startup. To name a few:

• Drug screening orders need to be registered in an EMR and cached for our support teams to quickly access.
• Images of lab results must be screened by our clinical support team prior to acceptance. They must then be automatically uploaded to our EHR and associated with the respective drug screening order.
• There must be a randomizer that supports different testing intervals, vacation ranges, testing preferences, and manual override.
• We must accurately track patients’ inventory, trigger shipments when patients need more supplies, send tracking information to patients when available, and cache shipment information to easily surface it to our internal support teams.

Let’s break these requirements down into their constituent components:

EHR

Our practice uses AthenaHealth as our EHR for the following core purposes:

• A source of truth for all appointments, prescriptions, lab orders, and medical information. While we cache this information in other systems (GCP DataStore, BigQuery) for easier analytics and better runtime performance of layered applications, our EHR is the primary source of truth for all clinical information related to the patient.
• Sending prescriptions and lab orders. We leverage Athena’s in-built interface with SureScripts and in-built interfaces with Quest and LabCorp for all outbound orders.
• Provider Appointment Workflows. Providers record their clinical encounters in Athena, from check-in to intake to exam to check-out.
• Claims Billing. A topic for a much longer post, but we leverage Athena to run eligibility checks and manage a portion of our claims billing process.

All this to say, an interface with Athena was a core requirement of our product effort. Lab orders needed to be registered in Athena, lab results had to be uploaded to Athena, and interpretations of those results needed to be performed and stored in Athena. Through some creative Task Assignment Overrides (i.e., in-built automation rules) and after many hours of speaking with their CSC, we were able to find a way to make their in-built orders system work for us:

• On the date we want to prompt a patient to complete a lab order, we programmatically create a lab order in Athena.
• Once a day, a medical assistant signs off on all those orders through bulk action.
• When lab results are submitted, they are automatically uploaded to the patient’s chart, associated with the most recent lab order, and an interpretation task is created for the medical provider.
• Medical providers interpret the result and file it away in the chart.

Not surprisingly, this was the most cumbersome integration to perform, due to the finicky and poorly documented details of Athena’s API.  

Shipping Vendor

The vendor selected for our warehousing and shipping needs, has a robust GraphQL library of APIs and webhooks which allow us to place and cancel orders and receive shipping updates. The vendor selection was primarily conducted by our operations team on the basis of cost structure and reliability, but from the product side, we have been very happy with the level of responsiveness and reliability we’ve seen with our integration.

Tracking Vendor

The shipping vendor’s status webhooks stop after the order is shipped, but we would still like to automatically send tracking information to patients and internally register when an order has been delivered. There are a number of vendors that are able to take tracking numbers, create tracking pages for customers, and send webhooks for status updates (received by carrier, out for delivery, delivered, delivery failure, etc.). We chose AfterShip due to its market prominence, reasonable price point, robust API library, analytics on time to delivery, and branded tracking pages. No BAA was required due to the HIPAA conduit exception, as we purge tracking information from the system once no longer needed. 

Patient App

In our patient app, we are building a react-native UX for patients to (a) receive push notifications when they are due for a random drug screen and (b) upload results directly in the app when appropriate. Those results get automatically uploaded for review by our clinical support team, and post review, they get automatically added to the patient’s chart for provider review. 

Internal React App

Internally, we have built a react application which we call the “Oracle” (no relation to the company Oracle Corporation). We’ll certainly cover other functionalities of the Oracle in other blog posts, but on a high level, our Oracle frontend allows our clinical teams to much more efficiently conduct operations like scheduling, finding low-cost pharmacies, and generating personalized induction tools. On the backend, the Oracle processes all automations related to different CRM and EHR events.

In the context of our toxicology process, we rely on Oracle for a few key functionalities. First, on the front-end, it allows our providers to specify all parameters related to a patient’s toxicology schedule. Second, also on the front-end, it allows our clinical teams to quickly view a patient’s toxicology history, including a history of their lab orders, lab results, interpretations, and shipments. On the backend, Oracle is the primary API interface to and from Aftership, and Athena, and is also responsible for sending patients automated prompts to complete their toxicology tests.

How it all comes together: Clinical Protocol and End Patient Experience

Each patient receives several test kits at a time to keep them at home in a safe place. The test kits are available for use when a test is requested by their medical provider. Since accountability depends on the knowledge that a test can be performed at any time, the tests are ordered randomly, and the medical provider determines how often they’re ordered.

• When prompted to complete a test, it should be done as soon as possible.  Since test kits are always on-hand and people tend to pee at least once each day, it’s reasonable to assume tests can be completed same-day with few exceptions.  
• If an ordered test is not completed by the next day, the delay is considered as a sign of a potential treatment concern like a slip or relapse, and the patient’s provider will take steps to improve treatment success.  
• For upcoming vacations, other travel, or other times when a patient knows they’ll be unable to complete a drug screen, we allow the patient to provide notice of the dates of unavailability, and we’ll keep track of those dates and will not ask for a drug screen to be completed during that time.
• Sometimes we ask for a saliva drug screen to be completed during a video-visit with a team member.  This is also requested randomly. We compare the saliva results to recent urine results in order to be confident that both samples came from the same person.
• Sometimes we ask for a send-off test or a test collected as a nearby commercial lab like Quest or Labcorp.  This type of test allows for sophisticated measurement of the type and amount of buprenorphine present in the sample and can determine the difference between medication taken every day as directed and medication taken only sometimes or only very recently.

Medical providers review each drug test with patients and determine if the result supports effective treatment and progress toward goals, or if it suggests room for improvement. A result that supports effective treatment is completed within the required timeframe, has the expected temperature and appearance of a new urine sample, contains the medication that is prescribed, and does not contain drugs that are unexpected or inconsistent with the goals of treatment.  Favorable drug screen results lead to more flexible testing windows and longer prescription windows, whereas non-favorable results lead to a more frequent testing schedule and a more intensive cadence of visits with the patient’s medical provider.

Closing Thoughts

Our investment into a rigorous, robust, and automated drug testing platform will allow us to continue building towards a vision of excellence of care in our treatment program. As far as we are aware, our system of randomized drug screening is novel for a telemedicine clinic, and in many respects exceeds the rigor of many in-person programs. We hope that our system makes it as seamless as possible for both our patients and clinical staff to maintain an effective drug testing program in the treatment program across our clinic.

Photo by Pavel Danilyuk from Pexels