Documentation

Solving Documentation Burden

tl;dr

While we wrap up the last few details for Carbon, I want to use this post to talk about why we built it.

EHRs have been shoehorned into doing a lot of things over the last thirty years. They went from basic data storage tools to encompassing everything from practice management to ePrescribing, billing, prior authorization, patient communication, team communication, and clinical documentation.

However, the challenges that usually hit clinicians hardest are in clinical documentation. In fact, a 2019 JAMA Study found that 86.9% of clinicians attribute excessive data entry requirements to increased stress and burnout in the clinical setting. Additionally, 75.2% of clinicians blame “note bloat” for the same thing. This is a problem. So much so in fact that sometimes the easiest solution seems to be to “add AI” or “just use dictation.” And while both of those technologies have a role to play, they cannot be the only solution to the problem.

AI placed on top of bad UX is still bad UX.

To get to the bottom of this we need to uncover the deeper cause of these problems.

The Problems

The problem isn’t a technical one. Rather it comes down to two environmental problems.

  1. Collecting structured and unstructured data
  2. The “business” of healthcare and clinical services

While I don’t think a startup can “fix” either of these challenges at an industry level, we can build technology that bridges the gap between user-friendliness and these problems. That’s what Carbon is setting out to solve.

I’ve written about our approach to a block-based SOAP note builder before here. But today, we’re going to discuss what exactly we did and why we think it’ll work.

Introducing, Carbon

But, first a screenshot. Here is Carbon:

The basis for Carbon comes in its block-based editor. This editor provides a series of “tools” to a user at the click of a button or with a keyboard command. This allows the user to add the section they need at the appropriate time. And because the sections are pre-built, Carbon knows which sections are which. So if a user adds multiple Assessments to a note, Carbon will know that there are multiple Assessments and how many there are. This gives a user a fast way to build structured-unstructured notes.

Carbon’s blocks are also moveable. So not only does Carbon know which block is which, but it also knows what order they are in.

Why is that important? Because it gives us the foundation for extracting structured data out of the unstructured-ness of prose style writing. Clinicians are trained to document their encounters in prose-style SOAP notes. And yet computers need structured data to send back and forth. This system creates a substructure or foundation for the unstructured-ness that can be customized to the user’s desire.

Carbon’s first iteration is just this functionality. The purpose is to get this in front of users to figure out how to improve it. We have some hunches about what to do to make it better but the best way to improve it is to have users give us feedback about what will make it the best.

I’m under no illusions that this is going to magically make anything better. What we’re looking to prove is if can someone build a SOAP note quickly with it.

So how does Carbon fix our two problems above?

Firstly, we are bridging the gap between what is structured and unstructured data. Version two will add templating features and eventually we’ll add Natural Language Processing. By adding these features we give clinicians the ease of writing with prose they want in a way that a computer can understand and extract the necessary data for billing, coding, etc.

Second, in the U.S., the business of healthcare isn’t going anywhere soon (as far as I can predict anyway). So the focus for technology should be on bridging the gap between what is easy to use and what creates the most value for these businesses. By creating this editor experience we are making it easier to create structured-unstructured documentation which in turn is easier to analyze for billing and coding down the line. Additionally, by focusing on user-friendliness we are ultimately making the work-life better for clinicians which has an immense business benefit.

Obviously, the jump between that future and what is pictured above is a massive one. But that is why this journey is so exciting. All of these small decisions will add up to something much bigger down the road.

So, how do you signup for Carbon?

Carbon will be available soon at which point we’ll be inviting specific users to try it out and let us know their thoughts. If you’d like to be considered you can join the waitlist on our website here.

Until next week, ✌️