[candiddevmike]

> 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]

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]

How do you deterministically verify that information was correctly entered?

Is it just

  validates :email, format: :email

In Rails?

[arcb]

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]

If you have an API, why are you using browser agents?

[arcb]

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).