Case Study: An overview of Sherpaa’s Custom-Built Platform

Sherpaa began building our own tech platform back in late 2012 to power a new kind of healthcare delivery. We built our own because, still to this day, there are no EMRs on the market that are hired to do the following jobs:

• Empower structured, robust online doctor/patient communication

• Create real-life conversational and diagnostic data, not billing data

  
  

Background

Sherpaa was founded by The Future Well founder, Dr. Jay Parkinson. Sherpaa operated from February 2012 to December 2020 and cared for ~30,000 patients across 45 states in America. Our clients were initially forward-thinking tech companies, and over the years, transitioned to governments and TPAs. Sherpaa was acquired in 2019 by Crossover Health.

Sherpaa was a unique process of healthcare delivery:

We were not paid from insurance companies so our technology did not need to be a billing engine. And because 98% of our doctor and patient communication happened via messaging within Sherpaa’s app, our doctors didn’t have to talk with the patient and then document during or afterwards. The communication is the documentation. That, in and of itself, made our doctors markedly more efficient than traditional doctors.

Sherpaa’s platform was a doctor/patient communication and project management tool.

Sherpaa actually had two applications. The first was the Care Team web application so our doctors could deliver care to large populations of patients. And the second was for patients— both a mobile app and a web app. In Sherpaa’s platform, the vast majority of communication and problem solving occurred within “Episodes of Care (EOC)” created by patients. Within a particular EOC, our doctors had “modules.” Each module had a state (essentially an “open” or “closed” state) within our backend. The modules were:

• Message with the patient

• Ask questions of the patient

• Order labs

• Prescribe medications

• Order imaging

• Refer to a specialist

• Refer to a facility

• Document a chief complaint

• Make a diagnosis

• Add a treatment protocol

The open and closed states of our modules were vitally important to keeping track of activity that happens both online within our platform (new messages, etc.) and offline in the real world (specialist appointments, imaging results, etc.). It ensures that with all of these online and offline moving parts, nothing falls through the cracks. We can see where EOCs stall and what and who we’re waiting on to take the EOC to the next step toward resolution. The ultimate goal of every EOC is to convert open (“incomplete”) modules into closed states (“completed”) and ensure EOCs were moved along through the natural life cycle of healthcare problem-solving.

Think of our platform as:

• An EMR (e-prescribing, referrals, etc.) built around online messaging instead of oral conversations in exam rooms

• A project management tool (a pneumonia is a project with all kinds of moving online and offline moving parts to be managed over time)

• A Contact Relationship Management tool (specialists, urgent care centers, ERs, radiology centers, etc.)

We built this ourselves because I wanted to be able to target each step of our care delivery process and optimize that step. And there was simply no viable solution for us out there. EMRs are hired to bill insurance companies and interpret oral conversations and procedures into billing data. All of the communication that happened within Sherpaa was captured perfectly because it was text-based real-life communication written by either doctors or patients. We did not have to take that conversation and convert it into inflated billing codes in hopes of getting maximum reimbursement from insurance companies. This freed us up to build technology focused on real-life data and efficient problem-solving unique to our one-of-a-kind process. 

By the way, all screenshots included here are not actual patient names nor real patient information. They are designs and do not reflect the content with our platform.

Patients have a web, iOS, and Android Sherpaa app

I’m going to go through each component of our tech, but first, watch our video to see how our tech works for patients.

Care Team Dashboard

Our doctors were taking care of a large population of patients. There were lots of online and offline moving parts. Patients could:

• Create Episodes

• Answer structured question sets

• Approve or deny e-prescriptions

• Approve or deny referrals

• Approve or deny lab or imaging tests

• View diagnoses

• View care plans

This meant our doctors had to be alerted that there was new activity within the population:

• A new Episode

• A new message within an Episode

• An e-prescription denied by the patient

• A referral denied by the patient

• A test denied by the patient

In general, Episodes were organized according to who’s responsible for next steps to keep the case moving toward resolution. Our dashboard only showed our doctors cases where they were responsible for next steps. Think of this as automated “To-Do’s” for our physicians.

When a Sherpaa doctor visited her dashboard, she is presented with new activity within their patient population as a series of To-Do’s

An Episode could be in one of two categories:

• Doctors are responsible for next steps (ex, replying to a new message)

• Patients are responsible for next steps (ex. Approving an e-prescription)

The dashboard was designed to surface all this new activity prioritized by Episodes that were labeled by our doctors as time-sensitive issues. Most of the time, doctors were working within Episodes and occasionally going to the dashboard. This meant doctors needed to be alerted of new activity while they’re working in cases. If they were working on a non-urgent case and activity happens on an urgent case, they needed to be able to stop and go to the urgent case.

The dashboard was also designed to only show doctors activity where they are responsible for next steps. For example:

• Read a new Episode or new message within a Episode

• Read question sets answered by patients

• View denials by patients so they can figure out next steps for when a patient denies a medication, referral, or test

• Review labs, imaging tests, or specialist consults

We patented the concept of a patient digitally approving or denying a doctor’s order before the order can be put through. We thought this was important because giving the patient the opportunity to deny an order meant we could work together with patients to find a plan they agree to. The old-fashioned patriarchal idea of “compliance” mostly stems from patients not understanding the plan or not believing in the plan. The goal for Sherpaa’s doctors was to get patient buy-in for a solution that will actually be carried out by the patient in the real world.

Doctors can of course search for cases using many different criteria. For example, show me yesterday’s patients I prescribed amoxicillin for and also ordered a CBC.

Messaging with Patients

Messages could be simple unstructured text just like an email. Our doctors could attach photos, pdf’s, and other files. It’s pretty simple. Create a message. Hit send.

Backend states for the messaging module are:

• Message sent to patient, not yet read

• Message sent to patient, read, awaiting response

• Message sent to patient, read, responded to by patient

Asking Questions

Over Sherpaa’s lifetime, we identified the top ~250 chief complaints people had for using Sherpaa. These are things like headaches, abdominal pain, asthma, etc. They’re nothing out of the ordinary, just your bread and butter primary care complaints. Just as traditional PCPs get really common simple things, we did too. And just as PCPs identify and diagnose serious things like cancer, so did we. So, for each complaint, over the years we built out multiple questions every doctor should ask each patient with a particular complaint. The series of questions were designed, in a checklist-driven way, to rule out serious issues, but also to give our doctors a complete description of the story. The number of questions for each complaint could range from 10 to 30. After the doctor read the patient’s initial story told in their own words upon creating an Episode, the doctor simply started typing the chief complaint(s). Upon choosing the chief complaint, that immediately loaded up the questions that are part of that question set. The doctor could edit, remove, or reorder each question within the set in case the patient already answered the question in their initial description. The patient then got a notification that they received a new set of questions to answer. Then, they answered each question in free text. It’s free-text by design because we found over the years that the best answers come from the patient’s own words, the “yes, but” answers rather than simply “yes or no.” The patient responded on their own time and terms and in their own words. Directing in-person patient responses to questions is one of the biggest time-consuming things doctors do. This type of asynchronous, checklist-driven questioning enabled our doctors to take a very accurate (aka safe) history in seconds.

Backend states for this module:

• Questions sent to patient, not yet answered

• Questions answered

Doctors chose the chief complaint(s):

Upon choosing the chief complaint, our system loaded a series of pre-filled questions doctors could edit, delete, or rearrange.

Ordering Labs

Doctors could document that they ordered labs within a case. We deliberately chose not to integrate with Quest or Labcorp for one reason. If you make it super easy to order tests, doctors spend your money too easily. The barrier we set up was the doctor had to log in to Quest or Labcorp to order the tests. The results were sent via pdf into the proper Episode within the platform and the doctor reviewed the results, commented on them, and then the patient was alerted they have new results and explanations.

Backend states for this module:

• Lab requisition created, not yet approved by patient

• Lab requisition created, denied by patient

• Lab requisition created, approved by patient, awaiting results

• Lab requisition created, approved by patient, results received

Doctors could simply start typing the name of the lab or choose from previous orders or most commons.

Upon choosing the test, they also chose the facility where the patient would have their labs drawn.

Prescribing Medications

Doctors could prescribe any non-controlled medications directly within an Episode via an integration with Surescripts. We worked with Surescripts to customize a process unique to Sherpaa’s asynchronous delivery model. Within an Episode, the doctor chose the medication which sent an alert to the patient to either approve or deny the medication. If the patient denied the medication, they entered the reason why which was sent back to the doctor to reconsider the next steps in the plan. If the patient approved the medication, they simply chose their pharmacy within Sherpaa’s app and they picked up the medication later. Again, we mandated that the patient approve or deny medications because we wanted to get patient buy-in to the care plan.

Backend states for this module:

• Prescription request created, not yet approved by patient

• Prescription request created, denied by patient

• Prescription request created, approved by patient, confirmed by pharmacy

Doctors simply type in the medication and input the details of the prescription.

From the patient’s web, iOS, and Android app, they could choose their pharmacy which then triggered the prescription sent to that pharmacy.

Ordering Imaging

Doctors could choose a specific x-ray, ultrasound, CT scan, or MRI to order and the facility they want the order sent to. Again, this sent the request to the patient and they either approved or denied the order. If approved, the order was faxed via our platform to the radiology center. We used fax because it’s the lowest common denominator that connects all of healthcare with zero tech integration. I’m a big fan of the fax to get things done quickly, simply, and in a HIPAA-compliant way.

Backend states for this module:

• Imaging requisition created, not yet approved by patient

• Imaging requisition created, denied by patient

• Imaging requisition created, approved by patient, awaiting results

• Imaging requisition created, approved by patient, results received

Doctors chose the test and where they want the patient to go for the test.

Referring to a Specialist

Sherpaa’s platform was part CRM because we had our own proprietary network of Sherpaa-friendly specialists each with profiles that can be chosen by our doctors and shared with our patients. For example, our doctors could easily find at the point of care within a case a neurologist in LA who takes Aetna, within 5 miles of the patient’s office, who specializes in migraines. The doctor would choose the specialist and the referral request was again sent to the patient to approve or deny the referral. Upon approving the referral, a referral note was sent to the specialist via fax with basic information about the patient, their insurance, and instructions for how to get the specialist’s report back to Sherpaa. Referrals stay “open” within our platform until it’s “closed” by obtaining the specialist’s consult report.

Backend states for this module:

• Referral requisition created, not yet approved by patient

• Referral requisition created, denied by patient

• Referral requisition created, approved by patient, awaiting consult report

• Referral requisition created, approved by patient, received consult report

Doctors either type the name of the specialist or the specialty and this presented the doctor’s options for a referral to a Sherpaa-friendly (curated/vetted) specialist.

Referring to a Facility

This was very similar to referring to a specialist but these were facilities like ERs, urgent care centers, radiology centers, etc.

Backend states for this module:

• Referral requisition created, not yet approved by patient

• Referral requisition created, denied by patient

• Referral requisition created, approved by patient

Doctors just typed the name of the facility or kind of facility to be presented with local Sherpaa-friendly options for the patient.

Making a Diagnosis

For each case, our doctors could choose from a limited subset of ICD-10 codes for diagnosing a patient. Each diagnosis code on our backend also had a patient-friendly name to mask the jargon that should only be presented to the patient. Each diagnosis had a short patient-friendly description along with links to the best resources on the internet to understand things in more detail. We didn’t want to compete with other entities that are much better at creating content than we were.

Adding a Care Plan (Treatment Protocol)

For the top 260 diagnoses, we created evidence-based protocols that could be easily customized for each case and sent to the patient. In many ways, this automated the majority of the communication of the diagnosis and the plan because this communication is routine and time-consuming for doctors. Each care plan has an introduction to the plan, most commonly prescribed medications, home-care instructions, contact sherpaa if, go to ER if, most common specialist referrals, most common facility referrals, and most common tests ordered. By presenting the most common options, doctors simply chose the most appropriate option, customized some content, and sent it off to the patient. The patient was then alerted they have a new message to read within Sherpaa.

There were a ton more details under the hood, but, for now, this is what we’re sharing. It was an elegant platform for both our physicians and our patients, it was rock solid, and it was custom-built to power an entirely new healthcare delivery model. And, at every point, It was about optimizing a doctor’s time and helping them automate repetitive tasks while making the asynchronous practice of medicine as seamless, thorough, accurate, and safe as possible.