Healthtech · Beyond Co. · Brazil's public health system

Absens Smart Scribe
with a SOAP note

Clinical documentation that listens to the consultation in real time, structures it into a SOAP note with ICPC-2 and ICD-10 coding, and delivers it into the e-SUS APS record, so the doctor can look at the patient again.

See the landing page Walk through the prototype

Role: Product Designer
Period: January to April 2026
Company: Beyond Co.
Team: Engineering, clinical advisory, product
Platform: Web, on desktop, used live in the consulting room
Context: Primary care units inside the SUS, Brazil's public health system
What you are looking at: A pilot, not a product at national scale. The figures below come from that pilot, and I mark which are measured and which are projected from it.

A clinician at a primary care desk with the record open on screen and the Absens recording panel over it, showing the patient name, elapsed time, and a control to end the capture — The scribe runs beside the record, not instead of it. The panel stays out of the way until the consultation ends.

The 60-second version

The constraint

The consultation audio is never kept, and the finished note has to land in the e-SUS APS record without overwriting a patient's history.

The decision

Design the screen around reviewing rather than writing, and treat the transcript as the source for every document the visit owes, not just the note.

The outcome

87% of notes accepted with no manual edit, and around 7 minutes of documentation returned to each consultation.

01 · Context

The chart is winning the consultation.

Doctors spend a third of the visit typing

In primary care, writing up the chart, coding it by hand and filling in referral forms eat the time that should go to the patient. The note still comes out incomplete.

~16 min

Of documentation per consultation, on average.

1 in 3

Record fields left incomplete.

Coding

ICPC-2 and ICD-10 are mandatory for reimbursement, and they are what gets wrong most often.

Three constraints that shaped everything

Privacy

No stored audio

Speech is streamed to the transcription provider under a data processing agreement, transcribed in real time, and discarded. Nothing is written to disk at any point in the chain. In the public sector this is not a preference, it is the condition for being allowed in the room.

Integration

Write without overwriting

e-SUS APS is the system of record and ends up holding the final documentation of the visit. The note fills fields, it never replaces a history.

Coding

Clinical responsibility stays human

A suggested code is a suggestion. The doctor signs the note, so the interface can never make acceptance implicit.

02 · Organising the work

Three waves, and the vocabulary you need to read them.

What went in, and in what order

Two things worth defining first

SOAP is the standard structure of a primary care encounter note: Subjective, what the patient reports; Objective, what the clinician observes and measures; Assessment, the clinical reasoning and the diagnostic hypothesis; Plan, what happens next. It is the structure e-SUS APS expects, so it was not a format we chose. It is the shape the record already has.

Regulation is how a primary care unit reaches everything it does not have. When a patient needs a specialist, imaging or a procedure outside the unit, the doctor issues a request that enters the public queue through SISREG, carrying a diagnostic code, a clinical justification and a risk classification. Today that request is written on paper during the consultation and retyped later by an administrative team inside the unit. Alongside it, the same conversation produces referrals to nursing and to other primary care services, and sick notes.

Wave 1 · capture

Capture tools and the SOAP noteLive transcription, speaker separation, and the note built field by field against the four SOAP sections.

Wave 2 · structure

Assisted codingICPC-2 and ICD-10 suggested per field.
Document templatesStarting with the regulation request, aligned with what SISREG requires.

Wave 3 · derived documents

Everything else the room producesReferrals, sick notes, and the templates a doctor builds for their own practice.

Deliberately not built

Filing straight into the regulation systemThe highest-value thing on the list. The reason it stayed out is in decision 1.

03 · Discovery

Each finding closes with the decision it produced.

What the evidence changed

1. A consultation does not produce one document

The starting complaint was typing. It slows the visit down and takes the attention that should go to the patient. But when we looked at what actually leaves the room, the SOAP note was only part of it.

Four moments of the same consultation: the paper forms stacked on the desk, the screen the doctor types into, a nurse carrying a printed request down the corridor, and the doctor reading at the end of the day — What actually leaves the room: the forms, the screen, the request carried by hand, and the reading that happens after the patient has gone.

The same conversation also produces regulation requests, routing to nursing and to other primary care services, and sick notes. All of them handwritten inside the same fifteen minutes. That reframed the product: the transcript is not raw material for a note, it is raw material for every document the encounter owes.

Decision 1What the transcript feeds

What we saw

The transcript could identify needs beyond the chart: regulation requests, routing to nursing and other primary care services, sick notes. Each one derivable from the same conversation, each one currently written by hand.

What we decided

Point the transcript at a set of documents rather than a single note, and prioritise two: the SOAP record, and the regulation documents aligned with SISREG.

What we cut

Automating the request all the way into the regulation system, so it would be filed straight from the consultation with no administrative sector inside the unit retyping it from paper. It is the highest-value item on the list and we did not build it.

What shipped instead

The request leaves the consulting room digitally and reaches the unit's administrative team already filled in, with the doctor able to track it. The retyping goes away. The queue integration does not, yet. That is a smaller win than the one we cut, and it is the one that fit inside a pilot.

2. Not storing audio has an interface cost

The privacy requirement is usually described as a legal constraint. In the interface it is a trust problem. With no recording to return to, the doctor cannot go back and check what was said, so the transcript on screen carries the entire burden of confidence in the note.

Decision 2Where trust in the note comes from

What we saw

Without a recording to fall back on, a doctor who does not trust a line in the note has no way to verify it, and will retype the whole thing.

What we decided

Keep the raw transcript with speaker separation visible next to the note, during the consultation and during review. Knowing which sentence came from the patient is what makes a generated line checkable.

What we cut

Short-retention temporary recording, which would have made auditing easier but created sensitive-data exposure the public sector would not accept.

What "not stored" actually means

It is worth being exact, because the sentence invites a fair question: if transcription runs on a third-party engine, does the audio leave the unit? It does, as a stream, under a data processing agreement with the provider. It is transcribed in real time and discarded. No recording is persisted, by us or by them, and there is nothing to retrieve afterwards.

3. Where a suggestion becomes a liability

Coding is the part of the note that pays the unit, and the part doctors get wrong most often. It is also where an assistant's confidence is most expensive.

Decision 3Granularity of acceptance

What we saw

Rejections were not wholesale. They concentrated in cases that needed a small edit, which meant the unit of acceptance was wrong rather than the suggestion.

What we decided

Suggest codes per SOAP field with individual acceptance, rather than for the note as a whole. A doctor has to be able to disagree with one line without discarding the rest.

What we cut

Silent auto-fill without confirmation, which would have removed clicks and quietly moved clinical responsibility onto the system.

04 · Delivery

Seven regions, one job each.

Anatomy of the consultation screen

app.absens.health/visit

Time saved17.5hper month, per doctor

Note completeness94%ready for review

Consent, live transcript, the generated SOAP note with its coding, and the regulation request built from the same conversation.

Live transcript with speaker separation

Doctor and patient speech visually distinct. This is the evidence layer, and it stays available for checking any generated line.

The SOAP note, field by field

The four sections are separate objects rather than one block of free text, so each can be edited and accepted on its own.

Completeness panel

A percentage of what still needs attention before saving. This is the primary object of the screen: the doctor's job is to review, so the interface's job is to show what is unreviewed.

The consultation screen: patient history on the left, the SOAP note in the centre with its raw transcript tab, the review panel with note completeness on the right, and the recording panel floating at the bottom right — Hover a region, or any of the three rules above, to see where it lives on the screen.

Code suggestions per field

ICPC-2 and ICD-10, attached to the field that produced them, accepted or rejected individually.

Regulation document templates

The referral request built from the same transcript, carrying the code, the justification and the risk classification the queue requires.

Templates the doctor makes

Custom document models, created and edited by the clinician. The set of documents a unit needs is not the same everywhere, so it could not be a fixed list.

Handoff to the administrative team

Regulation requests go straight to the unit's administrative sector, already filled in, with the doctor able to follow what happened to them.

app.absens.health/visit

Where the note goes next: the dashboard the unit reads, and the regulation queue the administrative team works from, with the request already filled in.

Why this is a desktop product

This is a product decision, not a gap. The consultation happens at a desk, with a keyboard, and the transcript and the note have to be visible at the same time. A phone cannot hold both without hiding one, and hiding the transcript is exactly what breaks the trust the rest of the design depends on.

Rules that hold across window sizes

Transcript and note

They never separate. The transcript is the evidence layer for the note beside it, so the layout carries a minimum width rather than stacking the two. Below it, the page asks for a wider window instead of hiding half the argument.

Patient list, completeness panel and task suggestions

All three collapse as the viewport narrows, and can also be retracted by choice at any width. What stays is the transcribed content and the editable documents, which is where the doctor actually works.

Accept and reject

Same affordance and same label everywhere it appears, so the action is learned once.

app.absens.health/visit

The same rules in motion. What collapses is context; what stays is the transcript and the documents the doctor edits.

Trade-off: writing into e-SUS without overwriting

Decision 4What we conceded and what we defended

The constraint

e-SUS APS is the system of record and history cannot be destroyed. Even with the integration in place, e-SUS ends up holding the final documentation of the visit.

What design adapted

We shaped our SOAP to carry the transcribed content in the structure e-SUS already expects, so what we write lands in fields rather than as an attachment sitting beside the record.

What design defended

No overwriting and no duplicated information. The review screen surfaces the critical points that need attention at the moment the doctor is reviewing, not after the record has been written.

05 · Impact

Measured and projected, kept apart.

What the pilot showed

Measured in the pilot

142

Transcriptions across the period.

87%

Of notes accepted with no change at all. The doctor read the generated note, agreed with it, and signed it.

78%

Adoption of the e-SUS integration, measured as the share of users writing through it rather than filling the record by hand.

94%

Integration success with the record, against a 90% target. Adoption is who uses it, this is whether it lands.

Projected from it

7min

Saved per consultation, the measured difference between writing the note by hand and reviewing a generated one.

≈17.5h

Recovered per doctor, per month. Those 7 minutes across a full caseload, not something observed over a month.* Based on an estimated 150 consultations per doctor, per month.

What that scales to

Same premise, applied to a whole unit. The figures are arithmetic on the 7 minutes, not separate measurements.

Doctors	Consultations / month	Recovered / month	Recovered / year
1	150	17.5 h	210 h
5	750	87.5 h	1,050 h
10	1,500	175 h	2,100 h
20	3,000	350 h	4,200 h

A unit with 10 doctors would recover roughly 175 hours of clinical time a month under the same premise. It is a projection, and it holds only while the 7 minutes holds.

How we tested

Two layers, because agents and doctors fail at different things.

Agents. Beyond Co. runs an in-house agentic testing solution, Volund, which uses trained agents to stress a product across a whole journey rather than a single screen. It is what catches the seams between steps: a note that saves but never reaches the record, a code accepted in one field and lost in another.

Doctors. On top of that, a field layer in a primary care unit in Recife, where the pilot was used by the unit's own doctors during real consultations. That is where the figures above come from, and it is also where the things an agent never reports showed up: the room's noise, the interruptions, and the rhythm of a real appointment.

06 · Learnings

Two things I would move earlier.

What I would do differently

Test more than one transcription engine quickly, and test its limits rather than only its quality. We chose ElevenLabs for transcription accuracy and language coverage, then had to design around a cap on how many transcriptions we could run in a period. A constraint like that changes the product, and we met it after the shape was already set.
Test in public primary care from the start, not only with doctors from private networks. A consultation in a SUS unit runs on different time, different equipment and a different caseload, and those are the conditions the product actually has to survive.