Over the last 2 weeks, I had the wonderful opportunity to work closely with Mark Pothen and Obinna Akahara in the 0 to 1 stage of their new startup Beacon Health, a healthcare workflow company seeking to save practices tens of thousands of dollars of lost value via improved and automated connectivity within their systems (think Zapier for healthcare).
When I opened Beacon’s codebase for the first time, I was intimidated. Up until now I had no experience working with large, company-scale databases. There is quite a jump in sheer number of files between a codebase for a week-long personal project to one that has been worked on for months.
So where did I start? The CLAUDE.md file: a spec for AI to understand the project and the best practices for adding and editing files. Yes, while its main purpose is to prevent mistakes to your codebase when developing with AI, I seldom hear people discuss how useful spec-driven development is for the human coders too. As I read through the more relevant spec files, I also felt more prepared to tackle the developments I needed to make. I was assured in knowing that both Claude and myself could always review the specs as we developed the integrations.
Speaking of integrations, my task for the 2 weeks was to integrate Spruce Health, a healthcare communication app, with the current UI being developed at Beacon. Additionally, I undertook a stretch goal of having a functioning workflow on Bland, a platform for AI voice agents. Before this internship I had only a surface familiarity with the healthcare industry technology in general, and its preferred software and tools. My eyes opened to just how many different systems are involved in a simple check-in process for a patient, and the various struggles of patient administration for their required checkups and followups.
My domain was a small piece of this system: if a new patient calls to make an appointment, the AI agent should be able to successfully initiate their profile on Elation (a health records platform) as well as Spruce Health. By the end of week 1, I readied action functions for the entirety of API endpoints as documented by Spruce, and passed scripted tests for a few of the highest priority actions. I found this section the most straightforward since there exists robust documentation and examples on best API action practices. I began facing my first big blockers once it came to testing on the proprietary UI.
A small company like Beacon is flexible and dynamic. While priorities change quickly, one of the benefits of their small size is making those changes on the fly seamlessly. But, this also means that as I fleshed out my integrations it quickly became apparent that some of the logic for how the UI ingests JSON must be updated in order to read a broader range of data structures. This was a significant change that required a deeper knowledge of the current system than I could gain during a short internship. I was, however, able to get two important Spruce actions working separately on the UI (create patient and send message), although connecting the two needs further development.
Obinna and I decided that the best use of my remaining time would be to further develop the current Bland workflow that he had started for when a patient calls the office. Working with Bland was fascinating, as this was the first time I was exposed to the other side of the decision making for the automated machines that answer when I call customer support. I saw how big of a task it is to try to encompass all possibilities of human conversation within a finite number of paths and nodes that an AI agent can go through. Of course, to be as helpful as possible to the user, there are nodes where the best thing you can do is to transfer them to another person. But there are plenty of useful actions you can integrate before reaching those endpoints.
I completed the integration from Bland to our back-end to Elation to successfully create a patient! Populating some necessary information in the notes section was the only missing piece of the puzzle. Fixing this was my final blocker. This process took me an hour to debug, as I kept making small modifications to the logic, meticulously scanning the Bland and Elation documentation, and asking Claude to find the error, all to no avail. I chose to step away from the problem, as I didn’t understand why it wasn’t working as intended, and when I came back I found it: the extra space at the end of a variable in Bland. Sometimes you need to learn the simplest lessons a second time, and this was one of those moments.
Thanks to my experience at Beacon, I am a more confident developer and I believe in the value of my input when discussing the design of larger systems. I deepened my knowledge on workflows, healthcare technology and working in large codebases. I am immensely grateful for this experience and Obinna’s guidance and trust in me. I want to include some his thoughts as well:
Hi! This is Obinna here :) It was a pleasure working with Dante, and it was great to read through this writeup! I think it captures a lot of our philosophy at Beacon for not only building AI systems, but building those systems with AI.
The most important principle is something that Dante alluded to at the start, systems that work well for humans, work well for AI. They are mirrors of our collective minds after all. So we hold that principle close, implementing derivative techniques like:
- Spec driven development
- Schema first development (Infrastructure as code)
- And documentation
We truly believe that AI will be the future of healthcare, and we’re dogfooding it by using it to build our company.
All in all, I look forward to diving deeper into the intersections of humanity and technology, automation and connection, and mapping where one ends and the other begins.