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