Co-Founding Regard

I was the technical co-founder and CTO at Regard, a digital health company I helped bootstrap and grow alongside my two co-founders, Eli (CEO) and Nate (COO / Sales). Today, Regard has found its clinical niche: post a $360M series B valuation it’s used in over ten health systems and has assisted with more than seven million notes.

But back in 2016, before it was a company, before we knew what a clinical note was, it was just the three of us in search of a problem. The classic startup inversion of cause and effect.

For my own records, here are the landmarks of my time with Regard. Standard disclaimer: this is written from my own perspective and nearly decade-old memories. The following doesn’t reflect Regard’s position.

Knowledgebases: A Solution Without a Problem (2016Q3)

Eli and Nate reached out to me in the summer of 2016. We were friends from our undergrad at MIT, and Eli had recently wrapped up his MBA at Stanford and was working with Nate to identify a problem the market might pay for. While both had some coding experience – mostly scripting and prototyping – it wasn’t their specialty nor what they wanted to do in the long-term. That’s where I entered the picture: I’d spent the last five years primarily as a software contractor working with startups on products and open-source solutions: startup software engineering was my passion and all I wanted to do.

At Stanford, Eli was exposed to DeepDive, a weak supervision methodology out of Chris Ré’s Hazy Research Lab that later grew into the unicorn Snorkel AI. At the time, Eli and Nate thought they could use DeepDive’s data extraction to build a knowledgebase out of high quality journal articles. However, other than some early conversations with SF-based PLOS for vetting journal submissions, they didn’t yet have a working product let alone market interest.

In July we met up in Los Angeles at a friend’s house (thanks Luke Xie!) in K-Town to 1) hack together on the knowledgebase, and 2) see if we wanted to work together. While we did play well together, the experience revealed the lack of direction: we could build a knowledgebase, but didn’t have evidence whether it was solving a real problem. I’d seen this anti-pattern of building before testing destroy some of the early-stage startups I’d worked with. And, I had plenty of exposure to the antidote through my wife, Caitria’s, professional work in user research: talk to your customers.

Searching for a Problem: Cold Calls from the Garage (2016Q4)

So, we pivoted from building the knowledgebase to pitching raw ideas to anyone who would listen. In particular, all three of us were interested in medicine due to past experience (we’d all considered being physicians, and I’d been accepted into med school before deciding to pursue tech) and the opportunities in a domain artificially limited by regulation, burdened by risk-averse technology stacks, and fractured into disjoint data silos. The original formulation of the knowledgebase was, clinical: evidence-backed medical content to support physician decision-making. But, we lacked a clear problem. What decisions, exactly, were we supporting? Did physicians or hospitals aeven care? And, customer research suggested they already had mature solutions like UpToDate and IBM Watson.

We spent the last six months of 2016 interviewing physician friends and cold-calling executives. Many of the conversations crashed and burned (“wait – how did you get this number?”) but some were eye-opening. We started to see the contours of the US clinical landscape in sharper relief – this was the first time I heard the refrain “If you’ve seen one hospital you’ve seen one hospital”, and I began to understand hospitals spend money on solutions that improve patient care only if they also increase ROI or satisfy regulatory requirements. We narrowed in on clinical improvements that affect hospitals’ bottom-line, things like 30 day readmissions, improved surgical scheduling, and automated scribing. But, we were unaffiliated with hospitals – without a partner we’d be building in the dark.

Cedars-Sinai TechStars Accelerator: HealthTensor is Born (2017Q1)

We found our first hospital partner via the Cedars-Sinai Techstars Accelerator. We’d spent the last six months working out of Eli’s SF hybrid garage-room and my backyard studio in Redwood City , but by the end of 2016 we were running out of savings and our significant others’ goodwill (thanks you again , Caitria). We decided to make a last ditch effort by joining an accelerator. We spent down some of our remaining budget to incorporate as HealthTensor and applied to the second Cedars-Sinai Techstars class with our top concept to date: a digital “scribe” that would record the physician / patient interaction and automate downstream actions.

The accelerator was a three-month program run by veteran Techstars manager Matt Kozlov. During the application interviews Matt let us know that he didn’t like the name HealthTensor nor was he sold on the scribing direction. But, he did admit us as “wet clay”, i.e. a pre-idea startup that would leverage the accelerator’s access to Cedars-Sinai to identify a problem and prototype a solution. Credit to Kozlov: he saw us clearly, and connected us with exactly the resources we needed (including a much-needed $100K convertible note).

For the first two months of the accelerator we tried to find a problem valuable to both Cedars-Sinai and its patients. Before the accelerator we were lucky to chat with one person per day, during the accelerator we had to divide and conquer, scattering across Cedars-Sinai to shadow physicians and interview leaders in parallel, collating their ideas and stress-testing them against the accelerator’s advisors and our own experience. The level of access was incredible: we spoke with people ranging from Dr. Bruce Gewertz, the Head of Surgery, to Robert Hacker, the Director of Facilities, to nurses and care coordinators.

Alongside our clinical exposure, as the tech guy I met weekly with Dr. Ray Duncan, Dina H., and Ranier V., an incredibly able group from Cedars-Sinai’s IT able to get stuff done so long as the request was reasonable. This was my first exposure to hospital IT, and I had to learn by trial-and-error. I’d describe an idea we had, break down the technical requirements, and they’d break down why it was unfeasible given the structure of hospital IT. Real-time data tended to be the blocker of our more ambitious ideas, with HL7 feeds of comprehensive data, which required a large investment for a hospital to stand up and supervise.

The Problem: Clinical Notetaking

Late in the accelerator program, amid this churn of ideas, we finally hit on a problem that was worth solving and matched to our skills. Eli was shadowing a hospitalist, Dr. Aaron Chiang, who was reviewing a patient chart. They both remember having the same realization: what if the process of reviewing data to write the clinical note could be automated, at least for common conditions?

Physicians tend to focus their documentation on the primary reason for admission, but clinical notes need to capture the full constellation of clinical conditions to support patient care and revenue cycle management. While patients may think of the clinical note as a tool for communication between health care professionals, clinical notes serve a second critical purpose: they’re how the revenue side knows what to bill for. Hospitals employ certified medical coders who review clinical notes and assign billing codes based solely on what’s documented. If a diagnosis isn’t in the note or is under-documented it can’t be coded, and therefore can’t be billed for.

Because documentation drives reimbursement, hospitals invest heavily in its accuracy and completeness. Most employ Clinical Documentation Improvement (CDI) teams, often made up of nurses or coders, who review notes and send physician queries to request clarification or additions. These queries, often delivered after an encounter, are a persistent source of frustration: overworked physicians feel like they’re tailoring their note for billing rather than the clinical reality.

Additionally, coders and CDI can only act on what’s documented. If a common condition like high blood pressure is left out entirely, coders won’t assign codes and CDI lacks the context and the mandate to query for an entirely new diagnosis. Given the sheer number of chronic and acute conditions many patients present with, documenting them all by hand can be a time-consuming exercise in clinical archaeology. Learning of this, our hypothesis was that by leveraging structured clinical data you could provide physicians with sharp tools to document correctly up-front you’d save them time while improving diagnostic completeness and reducing the need for CDI.

Validating the idea was straightforward. We worked with IT to pull a one-time data dump from Cedars-Sinai containing structured clinical data (e.g. demographics, vitals, medications) across a set of patients as well as the list of billing codes. By analyzing this dataset, we found missing diagnoses that affected the patient’s Hierarchical Condition Categories (HCCs). In other words, we demonstrated that Cedars-Sinai was under-documenting their patients and leading to lower reimbursement than they were entitled to. More importantly, those gaps could have clinical consequences. Omitting chronic conditions, such as depression, doesn’t change the acute care plan, but it meaningfully changes how providers interact with their patient, and lost revenue can ultimately reduce the clinical resources available.

Building the Prototype and Leaving the Nest (2017 - 2018)

At this point HealthTensor had identified a gap in patient care that was negatively impacting health provider revenue. We had a rough idea of the product that could solve this problem. We even had a marquee first client with Cedars-Sinai, one of the top hospitals in the world. For me, this meant I could build the prototype without reservation.

There were three challenges to develop the application: 1) creating a webapp that would write a clinical note given patient data, 2) HIPAA compliant cloud-operations supporting the webapp, and 3) the hardest part, integrating with hospitals to embed our webapp in the EMR and fetch clinical data in real-time. For hospital integrations, HealthTensor was able to leverage SMART on FHIR. SMART on FHIR was a relatively new standard, and provided a RESTful API where we could fetch clinical data on-demand. Critically, it largely delivered on the promise to create an “app store for health providers” from which a hospital could easily add our application to their configuration. HealthTensor pushed the envelope for SMART on FHIR’s data range and performance, but we had a viable path to build out our product.

Then, after about a year of progress we had our startup legs swept out from under us: Cedars-Sinai was not moving forward with HealthTensor. After the accelerator and further support, Cedars-Sinai was concerned they’d propped us up and were skewing development by removing the pressure of the open-market. I couldn’t argue with the logic, but from an engineering perspective having a hospital EMR to develop against was critical: the hardest part of our build was learning how to work with hospital IT. But, we were being kicked out of the nest.

Our Second Dance Partner: Torrance Memorial Medical Center (2018 - 2019)

Fortunately, we hadn’t been completely focused on Cedars-Sinai. Though pre-product, Nate and Eli had spent the last year pitching the idea to health systems and one local system in particular, Torrance Memorial Medical Center [TMMC], had shown interest. TMMC’s hospitalist division, led by Dr. Alexander Shen, understood the vision and were willing to go to bat with their hospital IT to get our prototype integrated. TMMC’s IT, in turn, was invested in the potential of SMART on FHIR integrations and wanted to gain experience standing up integrations with third parties. On the ground, this took months of uncertainty and navigating stakeholders, but by the end we again had a development partner for our prototype.

Seed and Growing the team (2019 - 2021)

Entering 2019, HealthTensor was again running on fumes. Early engineering hires like Cody Leff and Marcus Ansmann, brought on in 2018, sped up development but the accelerator’s $100K convertible note had nearly run dry. Eli turned his focus to fundraising with early stage funds and angel investors. We were still pre-revenue, handicapping fundraising efforts, but we landed a seed round which was extended in 2021.

This funding was the fuel HealthTensor needed to land its first few paying clients. Credit to Nate and Eli, who navigated the transition of the product from a freebie for development partners to a solution that hospital systems would pay for. It took marshalling the evidence on ROI and patient outcomes while navigating each hospital’s often-byzantine power structure. The best evidence, paradoxically, is existing successful contracts and word-of-mouth, and each contract made the subsequent that much easier.

To the Series A (2021 - 2023)

From 2021 to 2023 HealthTensor began to mature, hitting critical landmarks of recurring revenue, Series A funding ($15M round), and a growing team. Also, a branding agency left us with a new “blurple” color scheme and a more digital-health-friendly name, Regard. This was a time of stability and growth relative to our earlier scarcity.

With the Series A funding and a mature product the Regard began to actually hire for new functions. On the sales side it was time to move beyond founder-led sales, and Regard began to hire a sales team. To ensure hospitals had a good handoff we hired a team of experienced clinical trainers, led by Marcy Dzwill, who would travel on-site to teach physicians how to work with Regard and report back on the onboarding process. Engineering had evolved into something of a department, with frontend, backend, and operational teams – led by e.g. the excellent Kevin Hannigan and Michoel Burger.

But, by this point my role had become fully managerial, and I was looking for change back to my coding roots.

Wrapping my time at Regard (2023)

During my last year at Regard, starting in 2022, I tried to hire my replacement. I’d begun my job as a technical co-founder and helped develop a full-stack product from zero to one, but the job had grown into requiring a true CTO: for years my calendar was wall to wall with hiring, one-on-ones, check-ins, performance reviews, etc. While I might wish my skillset had grown in lockstep with the requirements, I was operating outside of my strengths and passions and no mentorship to help bridge that gap. So, I tried to find a Vice-President of Engineering [VPoE] to take on leadership of the engineering team, someone who did excel in the managerial side, who I could both lean on and learn from.

On a separate but related front, my parents were experiencing their own hockey stick as their aging seemed to be speeding up. For the first time, their responsibilities were sometimes outpacing them. I wanted a year to both spend time with my parents and help them transition to a more streamlined lifestyle they could stay on top of. I thought that once I hired a VPoE I could take a step back in both role and responsibilities – perhaps in a more remote role.

But, the hiring process for a VPoE took far longer than I expected and, in the end, it backfired. Skipping the more sundry details, the process left me with a team that knew I didn’t want to lead them and just as little time with my family. So I gave notice to the team and we set my last day in August of 2023. When the day came around, I offboarded myself like I’d done for others, handing off passwords and closing my own accounts, and then finally mailed back my work laptop.

Leaving Regard was bittersweet: the team at Regard was incredible and the product exactly what I’ve always wanted to work on. I still find my thoughts turning to how I might have handled things differently, whether I could have grown into an effective CTO. But, I can remind myself of what we built together at Regard and the time I’ve been able to spend with my family, the irreplaceable memories.

Regard has continued to grow in leaps and bounds, doubling in clients and raising a Series B at a $360M valuation led by Oak HC / FT. Generative AI was just making its impact known at the end of my tenure, and has massive promise to supercharge Regard’s offerings once safety and reliability are nailed down. My last project with Regard was Max Chat, a chatbot so physicians could chat about their patients’ data, and that is just the tip of the iceberg as genAI matures and its price falls. I’m incredibly excited about Regard’s future impact on physicians and patients – I believe the team is just getting started.