PRODUCT UPDATES · SEP 11, 2026 · 6 MIN READ
Adverse event onset dates, co-enrollment checks, and erasure on request
Week 37, 2026: AE onset dates are captured, co-enrollment is detected, an event recorded serious opens its SAE case, and patient data can be erased.
Burna AI Team

Week 37 of 2026 (September 7 to 13) taught Burna AI to record when an adverse event began, not only when someone assessed it. The adverse event onset date is now captured as a calendar date when the note gives one and in the note's own words when it does not, a co-enrollment conflict is named before a participant's credential is issued, and a patient's data can be erased on request, with any export they ask for produced first.
It serves the research coordinators and investigators who work adverse events, and the privacy and IT reviewers who ask what a deletion actually reaches. Seriousness also became a judgment a person records, in three states, and recording an event serious now opens its SAE case with a reporting clock set to the trial's own window.
AE onset date capture: a date, or the words the note used
Burna AI's grading pass returns three time facts for every adverse event: when it began, how long it lasted, and its pattern. Each now has its own place on the adverse event record.
- Onset. A calendar date resolves to a date. Any other phrasing, such as "cycle 3 day 7", is kept exactly as the note wrote it, because turning it into a date needs a dated cycle anchor, and a guessed date reads as a real one to every report downstream.
- Duration and pattern sit in their own fields, so a duration can never be read as a start date by a report composer or by the serious-event reporting clock.
- Provenance. The record says where each onset came from.
An onset dated after the encounter that observed the event is not treated as a beginning. The episode starts at the observation, and the note's own words stay visible beside it.
The patient's safety timeline now plots each event by when it began rather than when it was assessed, and keeps three states apart: an onset placed on a date, an onset stated in words that cannot be placed, and no onset recorded. A signed event that is still ongoing stays on the follow-up list, and an event whose ongoing status nobody has assessed is marked as needing that answer.
What a coordinator writes down decides whether an event can be graded and placed at all. How to document an adverse event so it can be graded covers the facts to capture at the visit.
Seriousness is recorded by a person, and it opens the SAE case
A CTCAE grade says how severe an event is. The ICH E2A criteria say whether it is serious. The two are separate judgments, and this week the record kept them apart.
- Three states. Seriousness is not yet assessed, not serious, or serious. Every event starts at not yet assessed, and a report leaves the field out until someone answers, so an untouched form never files a "not serious" that nobody decided.
- Who and when. Recording an assessment writes who made it and when, and that time starts the reporting clock.
- The SAE case. Recording an event serious opens its case: a checklist for chasing hospital records, the board's answer, the submission, the signature and EDC entry, each recordable whenever it happens.
- The trial's own window. The clock runs at the length the trial states, such as 24 or 48 hours. A trial that has stated none reads 24 hours and labels that figure as a default rather than the protocol's.
- Never from a grade. No surface counts, labels or reports an event as serious because of its grade, and the MedWatch trigger names the seriousness criteria.
Each trial also records, when it is created, the CTCAE publication it grades against and when adverse event collection opens, at consent or at first on-study treatment, because both are protocol facts that differ from trial to trial. What Burna AI does today lists the MedWatch, IRB and SAE reports these records feed.
Co-enrollment detection before a participant's credential is issued
A participant joins a study in Healthnotes, the participant app sponsors deploy through sites, with a PRO token the site issues on app.burna.ai. When that participant already holds an active credential on another trial, the issue drawer now:
- names the other trials before the token is minted;
- keeps the Issue Token button disabled until the coordinator confirms deliberately;
- records that acknowledgment on the audit trail, so a decision can be told apart from an oversight.
Concurrent participation may or may not be allowed by either protocol, and that call stays with the site. A request through the API without the acknowledgment is declined with the conflicting trials named, so the check holds whichever way a token is issued. Issuing a token for a participant on a single study shows no warning at all, which keeps the warning meaningful when it does appear.
PHI erasure and data export, export first
Erasing a patient now runs as a checkpointed sequence that resumes where it stopped:
- Block reads of the patient's records.
- Export, if requested: FHIR R4 bundles plus the application's own sections, assembled before anything is destroyed.
- Delete the patient's rows table by table, following a registry that gives every patient-keyed table an erasure verdict.
- Delete stored files, then the stored conversation context about the patient.
- Purge copy-forward records for a consumer, or redact their free text and retain them de-identified for an enrolled patient.
The account's identity is deleted only after the PHI side confirms the erasure. An enrolled trial participant's erasure opens under a regulatory hold, so nothing is destroyed until a person releases it, and litigation, safety-investigation and regulatory holds suspend destruction for anyone. Every step writes an audit row carrying counts and identifiers, never patient content.
The registry is pinned by a check: a new patient-keyed table that arrives without an erasure verdict fails it, so the answer to "what does an erasure reach" is verified rather than remembered.
One adverse event order on every screen
The grading tab, the drug attribution pane, the encounter summary and the encounter queue now share one order: grade descending, then confidence within a grade, then term alphabetically. The event the queue names as the lead is the first event in the detail pane.
An event with no measured confidence sorts after the measured events in its grade rather than being treated as zero, so a severe event with uncertain confidence still comes before a mild one. A coordinator reviewing a combination regimen can now read a graded event and its attribution row by row, in the same position on both tabs.
SMART on FHIR launch: fewer permissions, and Oracle Health launches complete
- Oracle Health (Cerner) launches now complete: the token exchange authenticates the way Oracle Health requires, and the app asks for the SMART scopes it is registered for.
- Fewer permissions. The launch requests no system-level scopes and no user-level clinical scopes: three practitioner-identity scopes to find the clinician's organization, and clinical reads scoped to the launched patient.
- The organization comes from the record. Where an EHR exposes no practitioner-role endpoint, the organization comes from the launched encounter's service provider. Either way it is the EHR's own reference, namespaced to the issuing system and never constructed.
- Community-hosted Epic deployments are recognized from the vendor's published endpoint directory.
- Straight to the encounter. The callback address carries the EHR vendor, so the launch context survives sign-in, and a clinician who is already signed in goes straight through. Clinicians who launch from the chart land on their encounters rather than on profile onboarding.
Launch configuration for iKnowMed (Ontada) was added in the same change.
Protocol Studio reviews a drawn trial schema
At protocolstudio.ai/redline, a person draws a trial schema as boxes and arrows. Protocol Studio reads the drawing into a typed graph, derives the schedule of assessments from the visits and ticks drawn, and runs four review rules written in code, such as a crossover drawn with no washout. Each finding names the boxes and arrows it was decided on, and the export carries the drawing, the schedule as a grid and every finding.
Also in week 37
- Study red flags reach monitoring. A severe symptom a participant reports on a study questionnaire now appears in the monitoring feed, the coordinator's own triage replies are left out so they do not read as new, and the all-clear waits on both feeds.
- Approved term mappings carry their approver. The approved mappings between CTCAE v5.0 and v6.0 terms, renames and one-directional substitutions alike, record who approved them as data, and a mapping with no recorded approver is not applied.
- Site counts from one source. The trial list, its rows and the detail page count sites from the record of which sites are linked to which trial, so the summary is never smaller than its largest row.
- Recorded visits go straight to grading. A recording handed to the encounter page shows grading as starting while the transcript loads, then grades the moment it lands.
- The Counted Voice Foundation's site. The Counted Voice Foundation, which provides Care Journal, gained its own site, now live at countedvoicefoundation.org.
Since then: In week 39 the same erasure sequence reached the Protocol Studio records of a linked patient.
AI suggests, clinicians decide. Human-in-the-loop, always.
To see onset capture, seriousness and the SAE case on your own trials, book a 15-minute conversation.