This week we’re still deep in building the narrative-based note-taking tool that powers Alloy. I do want to take some time to explain a bit about this process and why it may take a while.
When building software one of the biggest hurdles is making things reusable. If you use the same button everywhere, there’s no point in rebuilding the same button each time. It’s better to build it once and customize it for each use. This process is called componentization. Componentization is the process of building reusable components or elements that can be customized to the use case but have the same base functionality.
Our note-taking tool is a very component-based tool. In fact, it’s a tool made up of tools. These tools are just customized and different depending on what a user enters into them.
I’m not sure if I’ve talked about the SOAP note here before or not but if you’re not familiar, the SOAP note is the “standard” way that clinicians document a patient case. I put standard in quotes because the exact usage, order, and required detail seem to be up for debate. However, SOAP stands for Subjective, Objective, Assessment, and Plan. These four sections are how a clinician listens to a patient(Subjective), what they see and observe (Objective and Assessment), and what they intend to do about the issue (Plan). Our note tool will use the SOAP methodology with a bit more nuance to help clinicians build their notes by using Problem, HPI (History of Present Illness), Exam, and Plan sections to denote these pieces of information.
So what does this have to do with components? Take a look at the code block below.
<Note><Tool = "Problem"> Problem Heading Problem Text </Tool><Tool = "HPI"> HPI Heading HPI Text </Tool><Tool = "Exam"> Exam Heading Exam Text </Tool></Note>
You can see that we have a Note element denoted by the “< >” that has several different Tool elements inside of them. Each of these tools is one of the three sections of a note (yes, Plan is missing – more on that later). This is roughly how our note builder works. You can see that each section has the same information in it. A tool heading and tool text. This heading and text will be different for each tool. But the structure and functionality contained in each tool will be the same. Thus our goal is to build a single component that handles each type of content the same way.
This is where the hang up is. Not only do we have to build the base functionality but we have to build it in a way that makes it scalable and usable for each one of our tools. There are small nuances in each tool that we have to consider but the base functionality still needs to be the same.
To add to this, the type of functionality we are building doesn’t really exist anywhere. There are only a small handful of apps/services that have something similar and of course, they’re not sharing. We have found a library that gets us about 70% of the functionality we need, but the 30% it doesn’t have is a big deal. So the conversation is, should we build something totally custom to make 30% of our functionality easier to build? Or should we try to work within the library we have that is somewhat difficult to use?
If you’re interested in some more deep-ish dives like this, please let me know. This is the nitty-gritty of building an app.
