How Sherpaa’s Custom-Built Platform Powers an Entirely New Healthcare Delivery Model

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
  • Enable real-life conversational and diagnostic data, not billing data

Sherpaa is a unique process of healthcare delivery:

We are not paid from insurance companies so our technology does not need to be a billing engine. And because 98% of our doctor and patient communication happens via messaging within Sherpaa’s app, our doctors don’t have to talk with the patient and then document during or afterwards. The communication is the documentation. That, in and of itself, makes our doctors markedly more efficient than traditional doctors, who often regard themselves as highly-paid medical scribes.

Sherpaa’s platform is a doctor/patient communication and problem-solving engine.

In Sherpaa’s platform, the vast majority of communication and problem solving occurs within “cases” created by patients. Within a particular case, our doctors have “modules.” Each module has a state (essentially an “open” or “closed” state) within our backend. The modules are:

  • 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 are 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 cases stall and what and who we’re waiting on to take the case to the next step toward resolution. The ultimate goal of every case is to convert open (“incomplete”) modules into closed states (“completed”) and ensure cases are moved along through the natural life cycle of healthcare problem-solving.

Think of our platform as part Zendesk (case-based customer service), part EMR (e-prescribing, referrals, etc.), and part CRM (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 happens within Sherpaa is captured perfectly because it’s text-based real-life communication written by either doctors or patients. We do not have to take that conversation and convert it into inflated billing codes in hopes of getting maximum reimbursement from insurance companies. This frees 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.

Physician Dashboard

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

  • Create cases
  • 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 means our doctors must be alerted that there’s new activity within the population:

  • A new case
  • A new message within a case
  • An e-prescription denied by the patient
  • A referral denied by the patient
  • A test denied by the patient

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

When a Sherpaa doctor visits their dashboard, they are presented with new activity within their patient population as a series of To-Do’s

A case can 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 has been designed to surface all this new activity prioritized by cases that have been labeled by our doctors as time-sensitive issues. Most of the time, doctors are working within cases and occasionally going to the dashboard. This means doctors need to be alerted of new activity while they’re working in cases. If they’re working on a non-urgent case and activity happens on an urgent case, they need to be able to stop and go to the urgent case.

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

  • Read a new case or new message within a case
  • 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’ve patented the concept of a patient digitally approving or denying a doctor’s order before the order can be put through. We think this is important because giving the patient the opportunity to deny an order means we can 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 is 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 can be simple unstructured text just like an email. Our doctors can 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 the last 5 years, we’ve identified the top ~250 chief complaints people have 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 do too. And just as PCPs identify and diagnose serious things like cancer, so do 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 are designed, in a checklist-driven way, to rule out serious issues, but also give our doctors a complete description of the story. The number of questions for each complaint can range from 10 to 30. After the doctor reads the patient’s initial story told in their own words upon creating a case, the doctor simply starts typing the chief complaint(s). Upon choosing the chief complaint, this immediately loads up the questions that are part of that question set. The doctor can edit, remove, or reorder each question within the set in case the patient already answered the question in their initial description. The patient gets a notification that they’ve received the questions. Then they answer each question in free text. It’s free-text by design because we’ve 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 responds 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 enables 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 choose the chief complaint(s)
Upon choosing the chief complaint, our system loads a series of pre-filled questions doctors can edit, delete, or rearrange

Ordering Labs

Doctors can document that they ordered labs within a case. We’ve deliberately chosen 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’ve set up is the doctor has to log in to Quest or Labcorp to order the tests. The results are sent via pdf into the proper case within the platform and the doctor reviews the results, comments on them, and the patient is 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 simply start typing the name of the lab or choose from previous orders or most commons
Upon choosing the test, they choose the facility where the patient will have their labs drawn

Prescribing Medications

Doctors can prescribe any non-controlled medications directly within a case via an integration with Surescripts. We worked with Surescripts to customize a process unique to Sherpaa’s asynchronous delivery model. Within a case, the doctor chooses the medication which sends an alert to the patient to either approve or deny the medication. If the patient denies the medication, they enter the reason why which is sent back to the doctor to reconsider the next steps in the plan. If the patient approves the medication, they simply choose their pharmacy within Sherpaa’s app and they pick up the medication later. Again, we mandate that the patient approve or deny medications because we want 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 can choose their pharmacy which then triggers the prescription send to that pharmacy

Ordering Imaging

Doctors can choose a specific x-ray, ultrasound, CT scan, or MRI to order and the facility they want the order sent to. Again, this sends the request to the patient and they either approve or deny the order. If approved, the order is faxed via our platform to the radiology center. We use 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 choose the test and where they want the patient to go for the test

Referring to a Specialist

Sherpaa’s platform is part CRM because we have 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 can 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 chooses the specialist, the referral request is again sent to the patient to approve or deny the referral. Upon approving the referral, a referral note is 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 presents the doctor’s options for a referral to a Sherpaa-friendly (curated/vetted) specialist

Referring to a Facility

This is very similar to referring to a specialist but these are 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 type 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 can choose from a limited subset of ICD-10 codes for diagnosing a patient. Each diagnosis code on our backend also has a patient-friendly name to mask the jargon that should only be presented to the patient. Each diagnosis has a short patient-friendly description along with links to the best resources on the internet to understand things in more detail. We don’t want to compete with other entities that are much better at creating content than we are.

Adding a Care Plan (Treatment Protocol)

For the top 260 diagnoses, we’ve created evidence-based protocols that can be easily customized for each case and sent to the patient. In many ways, this automates 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 pick and choose the most appropriate option, customize some content, and send it off to the patient. The patient is then alerted they have a new message to read within Sherpaa.

There are a ton more details under the hood, but, for now, this is what we’re sharing. It’s an elegant platform for both our physicians and our patients, it’s rock solid, and it’s been custom-built to power an entirely new healthcare delivery model. And, at every point, it’s 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.