How HosTalky Uses PowerSync as the Sync Layer for Its AI-Powered Healthcare Platform

I first met the HosTalky team in March of 2025 when they were looking for a Realm replacement. We’ve had a long working relationship and they’ve helped us make various product improvements during that time. In this post I chat to them about their healthcare platform.

Background

HosTalky is a clinical workflow intelligence platform for healthcare teams: secure one-to-one and group messaging between clinicians, organization-wide announcements, shared reminders and tasks, personal notes, and CareID, a verifiable digital identity for healthcare professionals. Its core feature is an AI-assisted clinical scribe that turns a spoken clinical encounter into a structured clinical note in formats such as SOAP, H&P, Physiotherapy, DAP and BIRP; the same pipeline can also produce meeting summaries, follow-ups and results reviews. The apps run on iOS, Android and desktop, and HosTalky has been accepted into a leading U.S. health-system accelerator program.

When the team first mapped every vendor that stores or transmits PHI, the obvious subsystems were considered - transcription, the LLM, cloud hosting and the database, but the sync layer wasn’t part of the list:

“Candidly, PowerSync was not on the first version of that map,” the team told us. “We added PowerSync once we recognized that syncing note and message data to client devices means PHI transits, and is processed by, the sync service — which makes it a business associate.” In this interview, HosTalky’s engineers explain how they closed that gap with a Business Associate Agreement (BAA) and a HIPAA compliant configuration, and why they deliver AI-generated notes to devices through sync rather than polling.

Two things make HosTalky an attractive PowerSync case study. The first is that the team uses sync as the delivery channel for AI output: when a clinician stops recording, the note is generated asynchronously on the server, and the device learns that it is finished the same way it learns about any other change — the record updates. I call this inference-in-the-loop sync: it’s essentially synced event sourcing. The second is that they had to fit a sync engine into a HIPAA compliance architecture, and they were candid with us about where that was harder than expected. The interview below has been lightly edited for length and clarity.

App Details

Interview

The AI scribe

PowerSync
Walk us through the AI note feature end to end: a clinician taps record, and then what happens? What runs on-device vs. server-side, and how do Deepgram + OpenAI fit in?

HosTalky
A clinician taps record, and audio is captured on-device and streamed live to a dedicated WebSocket transcription service, which forwards it to Deepgram's real-time speech-to-text API. Deepgram streams back live captions during the recording, so the clinician sees text appear as they talk. When they stop, the client sends the accumulated transcript to our backend, which queues an async job and calls OpenAI to turn that transcript into a structured clinical note. The note updates in place once generation finishes.

In short: Deepgram handles live transcription in real time; OpenAI handles note generation afterward, asynchronously, server-side. The device captures the audio and displays the captions as Deepgram streams them back; the speech-to-text itself and the note generation both happen server-side.

PowerSync
Is one note backed by multiple recordings (for example, a clinician adding to the same note across a shift)?

HosTalky
Yes. Each recording pass is its own session, and a single note can be backed by several of them. If a clinician records again later in the same shift, the new session is appended rather than overwriting what came before, and the note is regenerated from the full history each time.

PowerSync
Do you keep the verbatim transcript or only the generated note?

HosTalky
We keep both, so the clinician can check the transcript if they have any doubt about the note. We keep the verbatim, speaker-labeled transcript on the note indefinitely, alongside the generated note, with no automatic expiry. The raw audio itself is not persisted on our side: it is used momentarily for transcription and then discarded.

PowerSync
Does the app treat an AI-generated note differently from one a clinician typed by hand?

HosTalky
Yes, and whether a note was AI-generated is recorded on the note itself rather than inferred. It drives the client UI: the transcript tab, and on desktop a confirmation before recording over a manually typed note. Server-side it determines how a note update is processed, since a manually typed note is handled differently from an AI-generated one being regenerated.

PowerSync
What are clinicians actually dictating - patient handovers, shift notes, personal reminders? Does any of it contain PHI?

HosTalky
The substance of a clinical encounter - patient history, conditions, medications, assessment and plan - so yes, it routinely contains PHI. That is precisely why the scribe path is treated as an in-scope PHI flow end to end.

PowerSync
Is AI anywhere in the messaging path, or only in notes?

HosTalky
Only in the notes and scribe path; clinician messaging is a separate path with no AI in it. We do have a separate AI assistant in the app, Medigenie, but that is its own feature rather than something layered onto chat.

Sync as the delivery channel for AI output

PowerSync
When a note is being generated, the client doesn’t poll an endpoint for status, the generating state is stored on the note and syncs to the device like any other data. Was that a deliberate architectural choice, and what did it get you?

HosTalky
Yes, deliberate. Generation status lives as a normal field on the note record and syncs down like any other data, rather than the client polling an endpoint for status. That gets us several things at once with no extra plumbing. The “generating” state survives an app restart, because it is just persisted data, not in-memory state tied to a live request. It works across devices automatically, since notes are scoped to the user rather than the device — if a note is generated on one device, any other device the clinician is logged into sees the same status update. And it needed no separate polling loop, retry logic, or push notification system, since PowerSync already handles keeping the client in sync.

PowerSync
Did you build it that way from the start, or did you begin with request/response and move to sync after something broke?

HosTalky
It started using synchronous API calls. Notes were originally generated through the same blocking request/response endpoint as everything else, so the clinician’s screen was stuck waiting until generation finished. For longer transcripts that wait got noticeably worse, since generation time scales with transcript length. That is what pushed us to move note generation onto an async job with status delivered via sync, so the client isn’t blocked waiting on the response and can move on while the note finishes generating in the background.

PowerSync
Do you stream partial output into the note as tokens arrive, or write the whole note once generation completes?

HosTalky
The whole note once generation completes — no token-by-token streaming. The generation step produces the full note text, then a single write updates the note’s content and flips its generating flag to false in one update. The client sees the finished note appear once, rather than watching it build up piece by piece.

PowerSync
What happens when generation fails or times out?

HosTalky
Generation is retried automatically up to three times; after that the job moves to a dead-letter queue and we get an internal alert. There was a real gap there, and we have a fix in review: originally no error or failure state was written back to the note, so if all retries were exhausted a note could keep showing “generating”. Sync only tells the client when generation finishes, not when it fails. The fix adds proper status and failure handling on the note itself, plus a timeout watchdog as a backstop.

Editor’s note: This lesson generalizes: if you deliver job status through sync, model and sync a failure status as data too.

PowerSync
What does the experience look like when a clinician records in a dead spot — cold storage, basement radiology, an ambulance?

HosTalky
Recording requires a live connection today, since audio streams to our speech-to-text service in real time rather than being saved locally first. If connectivity drops partway through, we stop the recording and generate a note from what was transcribed up to that point, with a clear error and restart prompt for the clinician. Fully offline recording (capturing audio locally and generating once connectivity returns) isn’t there yet. We are looking into ways to close that gap, including queuing the recording locally for processing once back online, and on-device transcription models so recording wouldn’t need a network connection at all.

PowerSync
Roughly how much of this would you have had to build yourselves if PowerSync weren’t in the loop? Things like a job queue, status polling, reconnect, dedupe logic, etc.

HosTalky
A fair amount. The AI job processing itself, namely the queue, workers, retries and dead-lettering, is something we built regardless since that is our own AI pipeline, not something PowerSync does. What PowerSync replaces is everything on the delivery side: a polling endpoint the client would hit repeatedly to check whether a note is ready, backoff and retry logic for that polling, reconnect handling so polling resumes correctly after a network drop, and deduping so the client doesn’t re-show a completion notification it already handled. Multi-device consistency would also be extra work, since we would need to make sure every device a clinician is logged into learns that a note finished, not just the one that requested it. With PowerSync, all of that collapses into watching a local database table for changes, since the sync engine already handles the connection, retry and delivery guarantees underneath it.

HIPAA and the compliance architecture

PowerSync
You have BAAs in place with Deepgram, OpenAI and MongoDB. How did you approach mapping which vendors touch PHI, and where did a sync engine fit in that map? Did you initially think of PowerSync as a data processor at all?

HosTalky
We built a vendor-by-vendor map of every service that creates, receives, stores or transmits PHI, and required either a BAA or a design that keeps PHI out of scope for each one. Candidly, PowerSync was not on the first version of that map. Our initial list focused on the obvious PHI touchpoints: transcription (Deepgram), the LLM (OpenAI), cloud hosting (AWS) and the database (MongoDB). We added PowerSync once we recognized that syncing note and message data to client devices means PHI transits, and is processed by, the sync service — which makes it a business associate. Closing that gap, with the BAA plus a compliant configuration, is a big part of why this exercise mattered to us.

PowerSync
What has been hardest about assembling HIPAA coverage? The paperwork, the per-vendor plan-tier gates, or the engineering controls?

HosTalky
A mix, but the per-vendor plan-tier gates were the most recurring friction. HIPAA features — BAAs, zero-retention options, dedicated infrastructure — often sit on a higher plan than our actual usage needs, so we repeatedly had to weigh paying for a tier we didn’t technically need against the compliance requirement. The engineering controls were substantial but tractable, because roughly 70% of the safeguards were already covered by our existing ISO 27001/27701-aligned policy set. The paperwork was the least of it.

PowerSync
Under PowerSync’s shared-responsibility model, the client side (the local SQLite database and what happens to it over a device’s lifecycle) is the customer’s to secure. What does that look like in HosTalky?

HosTalky
The mobile apps use SQLCipher, compiled into the native build, with an encryption key that is generated on-device and stored in the OS keychain. On the device lifecycle side, an explicit logout clears the local database through PowerSync’s disconnectAndClear, wiping the synced data off the device. The same happens on login and on account switch, so a new user never sees a previous user’s data.

PowerSync
How do you think about HIPAA’s “minimum necessary” standard when deciding what each device syncs? Has asking “what does this device actually need offline?” changed how you scope things?

HosTalky
The design already reflects that thinking. Personal notes, for example, are scoped to their own clinician rather than the whole care team or organization, so a device only ever holds the notes that clinician created, not a shared pool. Ownership-based scoping like that is the default pattern across the app, which lines up well with minimum necessary.

Editor’s note: This kind of ownership-based scoping is expressed in PowerSync Sync Streams with a few lines of SQL and enforced server-side, so a device only ever receives the rows its user is entitled to.

PowerSync
Was anything about PowerSync’s HIPAA shared-responsibility model unclear, or something you’d want documented better?

HosTalky
The split was clear on the big structural pieces — the dedicated Atlas bucket-storage cluster in our own account, the network restrictions, and that client-side controls like local database encryption and device wipe sit with us. Two things we would have valued earlier or more explicitly. First, that HIPAA eligibility — BAA availability — is gated to the Team and Enterprise tiers; surfacing that path, and the requirement to bring your own dedicated bucket-storage cluster, right at the start of scoping would have saved us a cycle. Second, clearer guidance on the client-side expectations under the shared model. The docs are strong on the infrastructure side, but a checklist of what the customer owns on-device — local encryption, logout and wipe behavior, de-provisioning — would help teams self-audit against the model rather than inferring it.

Editor’s note: We’ve updated our docs based on this feedback.

Reliability, and what could be better

PowerSync
Is HosTalky reliable for your users today? Any sync- or data-related reliability issues?

HosTalky
Overall, yes — reliable for day-to-day use. That said, we do have a handful of known sync edge cases we are actively working through, mostly around reconnect timing: a dropped connection during resync, or a cold start after being idle for a while, plus a couple of cross-device message delivery gaps. None of these are widespread, but they are real and tracked. We have also started implementing background updating on mobile to help with some of these cases.

Editor’s note: We’re working with the HosTalky team to see whether our recently released Checkpoint Requests can help iron out these edge cases.

PowerSync
What do you wish were different or better in PowerSync today?

HosTalky
Constructively: the main thing is that HIPAA eligibility — the BAA — sits on a higher plan tier than our usage otherwise requires. Surfacing the HIPAA-eligibility path and pricing earlier, and offering a route for pre-commercial teams that need the BAA but not the rest of the tier, would help companies at our stage.

Closing thoughts

The main thing that stuck with me from this conversation is how little AI-specific infrastructure HosTalky needed on the delivery side. Once “this note is still generating” became a field on the note rather than the state of an in-flight HTTP request, PowerSync did the rest: the state survives restarts, reaches every device the clinician is signed into, and needed no polling, retry, backoff or data dedupe code.