Portfolio
Kris Pueblos, RN, BSN
Clinical Manager (Hospice) | Clinical AI Builder · Houston, TX
How much autonomy should an AI system get on a clinical record? None on its own. I shipped that answer.
This system puts AI to work on a clinical record — so it never acts alone: clinicians submit, independent validators check, a person decides. It is live in production. Drawing that boundary in the design itself is the product work. This is an independent product, built solo — I define the problem, users, scope and safety boundaries, write the specifications and acceptance criteria, and direct the build. Not an employer product.
This page is my portfolio — the complete product record for the two production systems below: the requirements, the workflow, the case study, the evaluation and the metrics, with my résumé one tab over.
Clinical Decision Support — Clinician AI Assist
Operating model: human-gated clinical decision support — clinicians submit, independent validators check, a person decides · clinicianaiassist.com · live, with demo patients
The problem
Hospice assessment information is fragmented across the referral packet, visit notes and the chart — and the data that looks reassuring is often the data that misleads: stable vitals, one good meal, one good transfer, while the trajectory underneath is declining. Reviewers, IDG teams and Medicare auditors each see a different slice of the same patient.
Users & the design answer
Hospice RNs, IDG members and Medical Directors. A hospice decision-support system that follows one patient record from referral to recertification — eight tools and two deterministic risk models working a single shared profile instead of disconnected tools. Every lane's work writes back to that one profile, and correlation is explicit: analysis output must name which systems contributed to it, and every system's latest completed work is quoted with its source named — nothing is withheld.
How every analysis reaches its reader checked
Workflow — eight systems, one profile
Nothing reaches the reader ungated. Most recent data supersedes older data across the profile. Feed law: Referral Audit + PlanChart (start of care) take no inbound feeds. PlanChart recertification uses all sources for its baseline.
The eight tools — and the two risk models on every profile
Architecture, block by block
One record per patient — identity, baseline, and seven tracked metrics (MAC, weight, height, BMI, PPS, KPS, FAST). A profile starts as a name only; everything after that is earned work. Every lane reads the profile and writes its completed work back to it. No lane keeps a private copy of the patient.
Every lane runs on a single engine: a learned pattern library grounded in CMS Conditions of Participation, LCD/MAC guidance and published clinical sources, combined with a live evidence check and an adversarial cross-check that argues against the first read. The library learns from every completed analysis.
Independent validation passes check every analysis against its contract, and a QA verdict — pass, or pass with limitations — records their findings with the analysis itself. The system never holds an output and never labels one do-not-release: it is tasked to analyze and give the analysis, and the clinician decides what to do with it.
Patient Chart Rating and Census Risk are computed entirely by code from completed outputs — the model never writes the score. Chart Rating weights each lane's most recent QA posture with the agency's SSVI standing; Census Risk lifts the same computation to every analyzed chart under one CCN, prices pattern evidence across five families, and derives its outcome likelihoods from census evidence alone. Both render their build-up and rationale next to the number.
All tools sit behind an account gate. Synthetic demo patients carry fully processed work in every lane and are shared read-only with every account — and an operations agent restores the demo environment to its baseline every hour, so the record a reviewer opens is always the same record. Every account-created profile is owner-scoped and invisible to all others — enforced in the data layer, and proven by a scripted cross-account audit.
Boundaries — enforced, not disclaimers
- No prognosis. Trajectory is tracked and scored — never predicted.
- No eligibility or certification calls. The determination stays human.
- No autonomous orders, nothing unattended. Every run starts with a clinician's submission.
- Autonomy is fenced to data and structure. The scheduled agents refresh public data, watch policy and flag guideline changes — they never run an analysis, and guideline updates are never applied automatically.
- No unsourced values. Every figure traces to a source, a calculation, or a labeled translation.
- Designed around FDA non-device clinical decision support principles; not FDA cleared.
Case study — evaluation proof
Case study — the false-stability defect. Testing caught a measurement whose date was changed making a declining patient look stable — exactly the failure this product exists to prevent, manufactured by the product itself. The response was not a patch on one screen: all five metric write paths were routed through a single gate, so a re-dated or out-of-contract value cannot enter the record by any route. Find it in testing, fix the root cause, make the defect class impossible.
Case study — privacy, verified at the database level. A scripted cross-account audit caught leftover permissive access rules that could have let one account reach another's profiles and reports — invisible from the UI, real in the data layer. The verified end state: a fresh account sees exactly the two read-only demos plus its own profiles; edits to a demo or reads of another owner's record affect zero rows. The sharing rule is proven, not intended.
Technology
Portfolio — the full record
The complete product record for Clinician AI Assist — the requirements behind each of the eight systems, how each one is evaluated, the metrics that define whether it is working, and the roadmap the evidence supports — written the way a product team documents a shipped product.
Agentic Systems — the autonomous layer, and the fence around it
Operating model: scheduled autonomy on data and structure only — never on a clinical record
One scheduled agent works a fixed seven-task rotation, one task per hour: a public-side site-error sweep; refresh of the public CMS data layer (SSVI, PAC PUF, Hospice Care Index, HVLDL, HIS, CAHPS); registry watch (OIG exclusions, NPPES, cost reports); the LCD and CMS-manual policy library; MAC page watching — CGS and Palmetto medical review, education, and TPE, SMRC and UPIC program announcements; clinical reference refresh; and an integrity sweep of counts, coverage and the audit corpus. Every run also restores the demo environment to its golden baseline. The rotation is deterministic — fixed order, fixed sources, fixed checks — and what a run finds never changes what runs next. Site errors are reported with evidence, never auto-fixed.
A second agent scans the system's completed analyses against current CMS, Coverage Database and MAC guidance. When a guideline one of those analyses rests on changes, it files an update alert on the owning account's dashboard: what changed, the source and effective date, and exactly where it would apply — profile, lane, section. Nothing is ever applied automatically. The clinician reads the alert and decides; applying anything stays a human act inside the lanes themselves.
The fence: both agents live entirely on the data-and-structure side of the system. Neither runs a lane, produces a clinical analysis, changes a QA state, or writes to a real patient record — the one standing exception is the demo reset, which restores demo data to baseline and nothing else. Clinical analysis stays what it has always been here: on demand, started by a clinician, checked by validators, decided by a person. Autonomy was added where it is safe — keeping the ground current — and kept out of where it is not.
Agentic AI System — Care and Living Guide
Operating model: autonomous fleet under specification and gate · live
The fully autonomous pole of my work. Clinician AI Assist is human-gated by design — on a clinical record, autonomy stops at the door. Care and Living Guide asks the opposite question: what can an agent fleet run end to end when the product is data, not a chart? It is a senior-care decision resource — a care-provider directory, Medicare coverage and cost guidance, and a medication library — researched, written, independently verified, and published by an autonomous fleet of specialized agents I designed and run as founder and Agent Product Manager, for seniors and family caregivers, mostly 60+.
The fleet — separation of duties
The hard part was never generation. It was verification — so the fleet is built as a chain of custody in which no agent approves its own work:
The specs are the product work
I designed the fleet's division of labor and wrote every agent's specification and quality gates: claim maps that tie each statement to its source, figure checks against the Ledger only, reading-level and language checks that run before the crosscheck, not after. Direction comes from measurement — Google Search Console data decides what the fleet builds and deepens next. I prototype with Codex; I do not write the production code.
The output, as of its dates
Status — live, growing, not yet monetized
Live and public. No ads run on the site today — the current phase is audience growth through Medicare's enrollment season; monetization is a deliberate later stage, treated as a proof milestone rather than a current claim.
Two systems, two answers to the same question — how much autonomy should an AI system get? On a clinical record: none on its own. On a data product: the whole operation, inside specifications and gates a person wrote and can audit.
Method — how I build
Every product starts from how the user actually works and who makes which decision — before any feature is discussed.
I write requirements, boundaries and acceptance criteria — what the system must do and must never do — and direct the build from them. I define and judge the work; I don't write the code.
Validators and adversarial cross-checks examine every output, and their findings are recorded with it for the clinician to weigh — the system analyzes, it does not hold its work back. When evaluation catches a defect, the fix addresses the root cause, not the symptom.
Claims get verified from the public side — live pages counted, cross-account access tested, audits run against published facts.
Résumé — separate page
The full résumé (professional summary, core competencies, experience and credentials) lives on its own page inside this portfolio.
Read the résuméFor recruiters
I am targeting Technical AI Product Manager roles in agentic systems and clinical decision support — the premium is the combination: practicing hospice clinical leadership plus a production AI system being tested by clinicians against real outcomes right now. Sign up, open a demo patient, and run the system.
Connect on LinkedIn