Perspective from the work itself.
This is where our engineers, architects, and product leads write about what they're actually learning building healthcare AI, agentic systems, and connected health infrastructure — not syndicated commentary, and not content written to rank. It changes as the work does.
Where AI belongs in the clinical and operational workflow
Most of the useful AI in a healthcare workflow today is unglamorous: summarizing a chart, drafting a note, flagging a care gap, prioritizing a work queue. The line we hold is that a model can surface information, draft language, and rank priority — but the clinical judgment, the diagnosis, the care decision, stays with a licensed person who can be held accountable for it. That boundary isn't a limitation we're waiting to lift; it's the design constraint that makes the rest of the system trustworthy enough to actually deploy. The interesting engineering problem isn't making a model more autonomous, it's making its reasoning visible enough that a clinician can quickly agree or override it.
Ambient documentation is the easiest AI win, and the easiest to get wrong
Auto-generated notes save real time, but only if the model's output is reviewable against the source encounter. Silent errors in a note are worse than no note at all.
A risk score is a starting point for a conversation, not an answer
A model that flags a patient as high-risk still needs to explain which inputs drove that score before a care manager can act on it responsibly.
What "agentic" actually means inside a healthcare operation
"Agentic" gets used loosely enough that it's worth being precise: an agent is software that plans and executes a multi-step task using a defined set of tools, within boundaries someone has explicitly set. It is not a system making unsupervised clinical or financial decisions. The operational work is in the governance layer — scoped permissions per tool, an audit trail for every action taken, approval gates before anything irreversible happens, and a clear escalation path when the agent hits a case it wasn't built for. Multi-agent orchestration adds a second layer of that same discipline: agents coordinating with each other need the same guardrails as a single agent talking to a human.
An agent needs a job description, not just a prompt
Defining what an agent is explicitly not allowed to do is more important to get right early than expanding what it can do.
Every autonomous action needs an undo path
If a workflow step can't be reversed or flagged after the fact, it shouldn't be the first thing you hand to an agent.
What makes a digital health product get used after week one
Sustained use in digital health rarely comes down to interface polish. It comes down to whether the product removes a step from a workflow someone was already doing, or adds one. A patient app tied to a real care event — a recent discharge, an RPM device reading, a medication change — earns attention because it shows up at the moment it's relevant. A care team tool succeeds when it fits inside the system they already work in rather than asking them to check a second screen. The products that fade after onboarding are usually the ones optimized for first impression instead of the fifth week of actual use.
Notifications don't create engagement, workflows do
A reminder only works if the action behind it is genuinely easier inside the app than outside it.
The best patient experience is invisible to the care team
Patient-facing engagement only holds up long-term if it doesn't create new manual review work for the staff behind it.
FHIR conformance is a floor, not a strategy
Passing a FHIR conformance test proves your resources are well-formed. It says nothing about whether two systems agree on what those resources mean — whether a "condition" in one EHR maps cleanly to a "problem" in another, whether a lab result arrives with the units and reference ranges the receiving system expects, or what happens when a Bulk FHIR export lands with partial or duplicate data. The real interoperability work is the canonical data model underneath the API: normalizing codes, reconciling identity across systems, and handling the versioning drift that happens when trading partners upgrade on different timelines. Standards compliance gets you in the room. The mapping and normalization work is what makes the data usable once you're there.
Passing $validate doesn't mean two systems agree on a problem list
Structural conformance and semantic agreement are different problems, and most integration failures live in the second one.
Bulk FHIR exports solve the transport problem, not the mapping one
Getting a large export off an EHR is the easy half; reconciling it against your canonical model is where the real effort goes.
The data fragmentation problem underneath every VBC contract
HCC and RAF risk adjustment, and the quality measures tied to it, depend on a complete longitudinal view of a patient — claims history, clinical encounters, and increasingly social and behavioral data, held together. In practice that record is split across payer claims systems, one or more EHRs, and care management platforms that don't share a schema. The result is under-captured risk, care gaps that go unclosed because no single system shows they're open, and quality reporting that reconciles data manually every measurement period. Fixing that isn't a coding accuracy problem first — it's a data engineering problem: getting claims and clinical data into one place, on one patient identity, before anyone tries to code or close anything against it.
Risk adjustment accuracy is a data problem before it's a coding problem
Coders can only capture what's documented and visible — most missed HCCs trace back to data that never made it into view.
Closing a care gap requires knowing it exists in the first place
Gap lists built on claims lag alone miss the encounters that would have closed them weeks earlier.
What changes once a healthcare product carries real production load
Once real patient data and real claims start flowing through a system, the engineering priorities shift whether or not the roadmap says so. Uptime, auditability, and data correctness start mattering more than the next feature, because a bug that silently corrupts a care plan or drops an RPM reading is a different category of problem than a UI glitch. Testing has to account for clinical edge cases, not just happy paths — a device that stops transmitting, a duplicate patient record, a claim that arrives out of order. Monitoring and on-call stop being an operations afterthought and become part of what the product actually is, because the team that built it is the team accountable when it doesn't behave at 2 a.m.
The feature backlog gets shorter once real patients depend on uptime
Reliability work competes directly with new features for engineering time — and in production healthcare systems, it usually wins.
Data correctness bugs in healthcare don't show up as crashes
A silently wrong value in a care plan or a claim can sit undetected far longer than an outage would, which is why validation and audit trails matter as much as test coverage.
Have a harder question
than a blog post can answer?
Tell us what you're building. We'll respond within 24 hours.