Spruce Visits: How Do We Build a Spruce Visit?

Part one of our series on Spruce Visits explored what a Spruce Visit is and why we’re so excited about their power to contribute to efficient, high-quality medical care. In case you need a quick refresher: a Spruce Visit is an asynchronous telemedicine encounter that uses an evidence-based, condition-specific algorithm to collect a strong initial history and physical exam from a patient and provide it in an easily reviewable format to a treating physician or other care provider.

Spruce Visits do no diagnosing, treating, or other medical decision-making of their own, but it goes without saying that their underlying algorithms need to be of the highest, unimpeachable quality in order for them to be safe and useful in patient care. In this article, we’ll discuss in detail how we build each Spruce Visit and why we think they represent a gold-standard in telemedicine that you can trust to help you care for the patients who trust you.

An overview of the process

Every Spruce Visit goes through the same creation and maintenance process, which we’ll go through step by step below. Here’s an overview:

1. Complaint/condition selection
2. Framework generation
   1. Literature search and evidence review
   2. Differential diagnosis formulation
   3. Determination of important history and physical exam items
3. Algorithm creation
   1. Draft generation
   2. Review by expert physicians
   3. Review by expert copy editors
4. Ongoing feedback and maintenance

1) Complaint/condition selection

Each Spruce Visit is tailor-made for a particular medical complaint or condition, so the first step in creating a new Spruce algorithm is to define exactly what type of patient presentation it will address. One class of patient presents for a specific complaint (e.g., “cough”), and we have constructed algorithms that address many such common symptoms, each with a broad and thorough consideration of possible underlying pathologies. Other patients, however, are best served when considered by diagnosis, such as a diabetic patient or a patient with known psoriasis. We also build algorithms for these patients, with the more bounded nature of the presentation allowing us to dig deep and ask important, disease-specific questions: Has the diabetic patient had symptoms that might indicate undetected hypoglycemia? Has the psoriatic patient had new joint pains that could be inflammatory arthritis? We also actively collect expert opinion on potential new complaints and conditions from physicians who use the Spruce platform, so our set of available algorithms is always evolving and always based on real-world medical practice.

2) Framework generation

Once we’ve picked a complaint (or condition) to target, we build what we call a “framework” around it. The framework is a collaboratively-edited document that is developed by the Spruce medical director and our expert consulting physicians, and it directly informs the algorithm that will eventually be produced. Each framework begins with a thorough literature review, and in this foundational piece, we gather and evaluate high-profile evidence and opinion on the standard of care for the management of the complaint in question. We seek out relevant textbook chapters, society guidelines, government health policies, review articles, and important primary research publications, surveying broadly within medical fields that might be considered authorities on the topic at hand. A complaint of “constipation,” for example, would trigger a search within at least the literature of gastroenterology, family practice, internal medicine, and emergency medicine: all fields that regularly encounter patients presenting with constipation.

The other sections of the framework then proceed from what is uncovered in the literature review. First, we generate a thorough list of differential diagnoses for the target complaint, focusing on pathologies that carry a high risk of morbidity or mortality. The patient is complaining of constipation, but are they actually obstipated and suffering an obstruction? Or maybe they have a dangerous electrolyte dysregulation and resultant bowel hypomotility? Could it be hypothyroidism or maybe even malignancy? All conceivable etiologies are explicitly enumerated.

After assembling this list of differential diagnoses, we next determine which data is necessary to traverse the entries on the list: which pieces of history, physical exam, and diagnostic testing are needed to exclude dangerous pathology and which are needed to arrive at the true, or at least at a working, diagnosis. We do this based on the evidence and expert opinion found in the preceding literature review, and the resultant set of data items includes history questions, physical exam maneuvers, laboratory tests, radiologic studies, and anything else that has been found to be important to a standard-of-care assessment.

3) Algorithm creation

When the framework document is complete, we begin to develop the actual algorithm that will power the Spruce Visit. We first take each facet of the history that was found to be important in the framework and convert it to a question in the algorithm, ordering the overall flow similarly to a typical medical interview and arranging it into digestible sections for the patient (e.g., “Your Symptoms”). Behind the scenes, we also map the questions to recognizable groupings, such as “HPI” or “Social History,” for later display to the physician.

While we design the algorithm, we also focus on efficiency, so that an extremely thorough, best-practices history doesn’t feel like a never-ending interrogation for the patient. We accomplish this in two primary ways:

1. Adaptive branching logic
   Some questions only need to be asked if other questions are answered a certain way. You wouldn’t ask a non-diabetic patient what their blood glucose has been, and neither do we. The engine that runs our algorithms has support for complex boolean logic, and we use it to ask the right questions of the right patients, sparing those who don’t need questioning and saving time without sacrificing quality.
2. Question grouping
   Some questions, such as social history behaviors, can be asked as part of a list when they are in written form. In person, these questions can only be asked one after another and answered one at a time, a tedious process. In a Spruce Visit, the patient can review the related questions as a group, saving them a large number of clicks and extra screens to get through.

With the history complete, we then build the physical exam. Spruce Visits enable patients to take high-resolution photos and videos, and we direct them step by step to capture the parts of the physical exam that are relevant to their complaint or condition. It may not be intuitive to think that a useful physical exam could be obtained asynchronously, but we’ve put extensive thought into how it works, and reliable patients can be very successful. Our recent article covering five ideal patients for telemedicine shows a few concrete examples of how you can make the physical exam of a Spruce Visit work for you and your patients.

Spruce Visit algorithms also include a number of features to keep you and your patients safe. Most importantly, each algorithm contains triage logic that watches for patients with potentially dangerous presentations and guides them quickly to appropriate care. Asynchronous telemedicine is excellent for many situations, but recognizing and avoiding the rare emergencies that can occur is critical to ensuring that time-sensitive interventions are not delayed. The triage functionality in every Spruce Visit accomplishes this and makes sure that you’ll never open a completed visit to find something that should have been seen hours before. Each algorithm also includes a system of embedded alerts that brings high-profile data to your attention at the top of every visit, helping you easily recognize possible complicating factors and cases that might require extra thought. With both the triage and alert systems in place at all times, Spruce Visits are designed for safety above all else.

After initial drafting, the algorithm is then extensively reviewed. Each algorithm is stored in a collaborative document, and expert physicians in relevant specialties assess them for medical thoroughness while experienced layperson copy editors provide suggestions to maximize clarity and accessibility for patients. One important thing to note is that Spruce Visit algorithms are built in a human-readable markup language called “SAML” that we developed here at Spruce. With only minimal instruction, anybody can follow the flow of a Spruce Visit in SAML, and this allows us to share the algorithms directly with our network of reviewers. Here’s an example of a question written in SAML (left) with its resultant display inside of a Spruce Visit (right):

4) Ongoing feedback and maintenance

After an algorithm has been thoroughly vetted, we release it for use by physicians and other providers on the Spruce platform. We welcome feedback on our algorithms at all times, and they are under constant review and maintenance. As new evidence becomes available, the algorithms can be and are updated, ensuring that your practice will always be at the forefront of current best practices.

We’re very proud of the technology that powers Spruce Visits, of course, but we’re equally proud of the rigorous development process and attention to detail that underpins each one. We believe strongly that modern medical care requires excellence in both technologic and human systems, and we work hard to exemplify both of these in every Spruce Visit, every time.