[HN Gopher] Launch HN: BitBoard (YC X25) - AI agents for healthc...
___________________________________________________________________
Launch HN: BitBoard (YC X25) - AI agents for healthcare back-
offices
Hi HN! We're Connor and Ambar, and we're working on BitBoard
(https://bitboard.work). We build AI agents that handle repetitive
administrative tasks in healthcare clinics like filling out intake
forms, prepping charts, or managing referrals. We were early
employees at Forward, which provided primary care across the US. To
scale this, we relied on thousands of remote contractors to do
repetitive administrative work like reconciling patient records,
and scheduling follow-ups based on care plans. It was a huge
bottleneck--expensive, error-prone, and always pulling attention
away from clinical care. Our software solutions were always too
brittle, never managing to handle the variance of clinical data we
oversaw. AI, when applied well, is capable of performing a lot of
the tasks we manually did. So we decided to take another crack at
the problem by building today what we would have liked to have back
then, and to help clinics use it. Clinics send us their SOPs
(Standard Operating Procedures--for example, "prep a patient chart
from these records before a visit"), and we turn them into AI
agents that do the work. These agents act like remote contractors:
they log into EHRs, navigate internal tools, and do the work in the
background. Unlike classical RPA, we build in verification and
deterministic checks, so customers can confirm it was done right.
Unlike low-code tools, there's nothing new to learn. Customers
don't have to touch a UI or maintain logic. They just hand us the
task, and we do it. Clinicians don't want more screens! They erode
attention and cause weird bottlenecks in operations because someone
has to drive them. Our product is built to address this. Here's a
demo video: https://www.youtube.com/watch?v=t_tQ0fYo85g. We're not
self-serve yet, but we deploy with customers in days after
onboarding them. We're working on speeding that up. One of our
early customers is a fast-growing obesity medicine group. Their MAs
were spending 15 to 20 minutes per patient just entering intake
form data into the EHR. That one task was taking up 30% of their MA
time. We took it over in a week. It's now fully automated, and
they've cleared the backlog and sped up visits. A few technical
problems are specifically relevant to building healthcare agents:
- Unreliable interfaces: many EHRs and clinic tools don't follow
modern web standards, making automation brittle. We've forked
browser-use to solve some of these challenges. We're working on
analogous infrastructure to let agents operate on desktops and
across a wide range of APIs. - Verification: in healthcare, tasks
need to be provably correct. We embed deterministic checks into
each workflow so agents can confirm the task was completed as
expected and the output is accurate. - Workflow generation: clinic
SOPs are written in natural language and vary widely, yet still
describe the actual process that works for clinics. We charge per
task, based on complexity. We're HIPAA compliant, audit-logged, and
operate in a zero-retention environment unless auditing requires
otherwise. A meaningful part is building trust in a high-stakes
environment like healthcare. Part of that is making the product
reliable. But another educational part is learning how to introduce
a new concept like "agents" to clinics. We're working on the right
ways to describe them, to onboard them, to measure them.
Endearingly, one of our customers' agents is named "Robert Ott",
and they refer to him by name in their weekly updates like he's a
member of the team :) We're learning a lot and have a long way to
go. We'd love to meet other folks who 1. work in medical groups or
health systems and want to offload repetitive work, and 2. are
building in this space and want to trade notes. We're happy to
share everything we've learned so far. And this is a big space,
with a lot of learnings from personal stories, from clinicians,
technologists, administrators, and more. What do you make of it?
We'd love to hear from you.
Author : arcb
Score : 37 points
Date : 2025-06-10 15:09 UTC (7 hours ago)
| candiddevmike wrote:
| > we build in verification and deterministic checks, so customers
| can confirm it was done right
|
| I didn't see this in your demo, how is this being implemented?
| You're entering fairly important information into EHRs like
| allergies and medications, that's more than just high-stakes,
| that's medical malpractice territory. I think you folks are
| really pushing the limits of the FDA's medical device exemptions
| for administrative work here. Are you working with the FDA on any
| kind of AI medical device certification?
|
| What EHRs do you integrate with?
| arcb wrote:
| Great questions. You're right that this is a high-stakes
| domain. Today, we only perform data entry in cases where we can
| deterministically verify that the information was correctly
| entered. Otherwise, we fail the task and flag it to the team.
| Re how - in the data entry case, we compare our source and
| destination data. For example, a JSON entry in our source must
| be present, without transformation, in the appropriate section
| of the EHR, verified by OCR. I'm taking a note to add this to
| our video. We also wouldn't take on anything close to diagnosis
| or treatment
|
| We're also not operating autonomously: 100% of our outputs are
| reviewed by the clinical team shortly after entry, as part of
| their regular process. That feedback loop is essential, both
| for safety and for evolving the system responsibly.
|
| Amongst EHRs we currently work with Athena, though we do a lot
| of work on isolated file stores that our customers create for
| us.
| ljm wrote:
| How do you deterministically verify that information was
| correctly entered?
|
| Is it just validates :email, format: :email
|
| In Rails?
| arcb wrote:
| It depends on the source and destination. The trickiest
| case is when we're using browser agents for data entry. We
| can use the fact that we focus on repetitive tasks to our
| advantage - we know what sections of UI we need to check,
| and for what data. We can verify correctness by re-
| extracting data from the destination UI (via the DOM or
| OCR) and checking:
|
| That all expected fields were entered correctly.
|
| That no unexpected or extraneous data was added.
|
| When we have access to a direct data source (like an API or
| file store), verification is simpler -- we can do
| deterministic checks and directly confirm the values.
|
| We're also building a validation library for common field
| types (dates, contact info, etc.) to enforce constraints
| and avoid propagating unverifiable or out-of-range values.
| candiddevmike wrote:
| If you have an API, why are you using browser agents?
| arcb wrote:
| We don't use browser agents if an when we have an API -
| we prefer the strongest data types we can access. It
| comes down to what our customers can work with. Some of
| them are fairly technical (have an IT team), and some
| aren't (have a legacy portal and operate on spreadsheets
| / paper).
| noleary wrote:
| You mentioned your early customer in obesity medicine.
|
| Are there specific kinds of clinics that are an especially good
| fit for you? Are you seeing any patterns in the kinds of clinics
| that are relatively eager to adopt an AI product like yours?
|
| I don't have any feedback on what you're up to, I just think it's
| interesting!
| arcb wrote:
| Thanks! From our side, we're currently focused on specialty and
| multi-specialty groups. For example, obesity medicine,
| cardiology, pathology centers, radiology clinics... These
| groups tend to have repeatable workflows and a lot of
| operational toil. That makes them a good fit for automation.
| Even modest time savings let clinicians go deeper on casework,
| or see more cases. We're also working with smaller and medium-
| sized groups (think 10 to 100 doctors), since it helps us sit
| directly with clinicians and get high-quality feedback.
|
| Compared to 3 or 4 years ago, clinicians are much more open to
| AI. They've heard of ChatGPT or ambient scribes, and they often
| come to us with specific ideas of what they want AI to solve.
| Talking to them is one of my favorite parts of the job.
|
| That said, we also hear a lot of of requests from groups that
| we have to turn down. Sometimes we can't guarantee success, or
| the product just isn't ready for that use case. As an example,
| a ton of clinical interfaces only work on desktops, which we'd
| like to support but don't yet. We're hoping to grow into those
| over time.
| ahstilde wrote:
| very cool! What's the biggest thing you learned from Forward that
| you're applying here?
| arcb wrote:
| Thank you! One of the big ones is that clinicians don't want
| more screens; they're already overloaded. So we're succeeding
| if we're invisible and yet effective for our customers. We're
| not dogmatic here - we can see customer-facing UIs being useful
| for focused and necessary usecases. For example, changing their
| process should be something close to an email or a chat with
| their agent, but not a complex process builder that they have
| manage runtime complexity in.
|
| Another is that once you free up clinician time, they will
| quickly find higher-leverage tasks. It shows how overloaded the
| system is, and that there's pent-up demand to make it better.
| MK_Dev wrote:
| This is a pretty cool idea and implementation. Any more details
| on the tech stack you guys are using (besides `browser-use`)?
| arcb wrote:
| Thank you! We have a fork of browser-use that lets us hand hold
| web agents since we know our tasks are repetitive. We can cache
| expected paths and fire alerts if we go off the rails. We'd
| love to contribute it back at some point, mainly a question of
| bandwidth.
|
| We're evaluating Cua
| (https://www.ycombinator.com/companies/cua) to containerize our
| agents; am a fan so far. We're also putting Computer Use agents
| from (OAI and Anthropic) to the test. Many legacy ERPs don't
| run in the browser and we have to meet them there. I think
| we're a few months away from things working reliably and
| efficiently.
|
| We're evaluating several of the top models (both open and
| closed) for browser navigation (claude's winning atm) and PDF
| extraction. Since we're performing repetitive tasks, the goal
| is make our workflows RL-able. Being able to rely on OSS models
| will help a lot here.
|
| We're building our own data sets and evaluations for many of
| the subtasks. We're using openai's evals
| (https://github.com/openai/evals) as a framework to guide our
| own tooling.
|
| Apart from that, we write in Typescript, Python, and Golang. We
| use Postgres for persistence (nothing fancy here). We host on
| AWS, and might go on premises for some customers. We plan on
| investing a lot into our workflow system as the backbone of our
| product.
|
| I prefer open source when possible. Everything's new and early,
| and many things require source changes that others might not be
| able to prioritize.
|
| Edit - one thing I'd love to find a good solution for is
| reliably extracting handwriting from PDF documents. Clinicians
| have to do this a ton to keep the trains running on time, and
| being able to digitize that knowledge on the go will be huge.
|
| Very open to ideas here. We're seeing great tools and products
| come up by the day, including from our own YC batch.
| terrib1e wrote:
| Are you hiring? I currently work at a large organization that
| administers govt contracts including the health marketplaces, so
| I have some insight into this stuff.
| arcb wrote:
| We're looking to hire our first few engineers in the next few
| months, and we would love to talk to anyone who has an interest
| in working in this domain! If you'd like to talk more we're at
| founders at bitboard.work and are fast to respond.
___________________________________________________________________
(page generated 2025-06-10 23:00 UTC)