HealthtechProduction AIEHR

Shipping AI Inside an EHR (Without Breaking Production)

Eight things I keep relearning while building EasyChart — the AI charting layer inside CloudNurse, where the model writes notes on real residents, every day.

AI Tech BearJune 20267 min read

A demo that turns a spoken sentence into a tidy vitals note takes an afternoon. An AI feature a nurse trusts at 2 a.m., on her fourth admission, over a flaky 4G connection, with a resident who switches between Thai and English mid-sentence — that takes the other eleven months.

The distance between those two things is almost never a better model. It's everything around the model. Here's what I keep relearning building EasyChart, the AI charting layer inside CloudNurse, our EHR for nursing homes and rehab centers across Southeast Asia.

01 Start with the workflow, not the model

Most clinical "AI" tasks aren't open-ended reasoning problems — they're workflows with a couple of decision points. Charting a Barthel Index isn't "be creative," it's "map this conversation onto ten well-defined fields." The moment you frame it that way, you can constrain the model, validate its output, and actually reason about failure. Reach for an autonomous agent only when you genuinely can't predefine the path — which, inside an EHR, is rarer than the hype suggests.

02 The model proposes, the clinician disposes

Nothing the AI produces should land in the chart on its own. EasyChart writes to a draft, never the record. A human reviews, edits, and commits. This isn't a UX nicety — it's the entire safety model. It keeps a person accountable for every clinical claim, it gives you a clean correction signal to learn from, and it turns a hallucination into an annoyance to fix rather than an incident to report.

A confidently wrong "BP 120/80" is far more dangerous than a blank field waiting for a nurse.

03 Structure is the product

The valuable output of clinical AI isn't prose — it's discrete, validated fields. So don't let the model free-write into the record. Constrain generation to your schema: enums for assessment scores, ranges for vitals, required units. When the model is unsure, the field stays empty and flags for review instead of inventing a plausible number. Empty-and-honest beats full-and-wrong every single time.

04 Design for the unhappy path first

The demo always uses clean audio and textbook English. Production is a TV in the background, a phone held too far away, and a resident code-switching mid-sentence. Build for that reality: graceful fallback to manual entry, partial capture that keeps whatever it got, and one hard rule — the AI can degrade, but it must never block care. If the model is down, the nurse charts the way she always has. The feature is additive, or it's gone.

05 Treat PHI like plutonium

You're handling some of the most sensitive data there is, under Thailand's PDPA and the quiet trust of families. That shapes architecture, not just policy. Hard tenant isolation, so one facility's data can never bleed into another's. Redaction before anything crosses your boundary. An audit trail that logs every AI suggestion, who reviewed it, and what they changed — both for compliance and because that record turns out to be gold for evals. And decide retention on purpose; "keep everything forever" is a liability, not a strategy.

06 Evals before features

Before I add a capability, I want a golden set: a few hundred real, de-identified encounters with known-correct fields. Then you can measure what actually matters — field-level accuracy, not vibes — and put a regression gate in CI so a prompt tweak that quietly tanks Barthel scoring never reaches a resident. In healthcare, "it seemed better in testing" is not a sentence you want to defend later. This is the same spirit as building effective agents: measure the system, not the magic.

07 Latency and cost are clinical UX

A nurse will not wait eight seconds at a spinner; she'll go back to typing and never open the feature again. Speed is a feature. Stream output so something appears immediately. Use the smallest model that passes your evals for each step — voice cleanup, field extraction, and summarization rarely need the same horsepower. Cache aggressively. The cheapest, fastest path that clears your accuracy bar is the right one; spend the big model's latency only where it earns it.

08 It's a systems problem, not a model problem

Put it together and the lesson is boring and freeing: the hard parts of clinical AI have almost nothing to do with the model. Boundaries, fallbacks, review states, audit, evals, latency. Get those right and a mid-sized model feels like magic. Get them wrong and the best model on the leaderboard still produces an incident. Build the system that has the nurse's back — and the AI gets to be the thing in her corner instead of one more thing to babysit.

AI Tech Bear
Healthtech executive and product builder in Bangkok, working where elder care, software, and AI meet. Currently building CloudNurse. See more work →
เฮลท์เทคProduction AIEHR

การนำ AI เข้าไปอยู่ใน EHR (โดยไม่ทำให้ระบบโปรดักชันพัง)

แปดเรื่องที่ผมได้เรียนรู้ซ้ำ ๆ จากการสร้าง EasyChart — เลเยอร์ AI สำหรับลงข้อมูลทางคลินิกใน CloudNurse ที่โมเดลเขียนบันทึกให้ผู้พักอาศัยจริงทุกวัน

AI Tech Bearมิถุนายน 2026อ่าน 7 นาที

เดโมที่เปลี่ยนประโยคพูดให้กลายเป็นบันทึกสัญญาณชีพเรียบร้อย ใช้เวลาแค่บ่ายเดียว แต่ฟีเจอร์ AI ที่พยาบาลไว้ใจตอนตีสอง ระหว่างรับผู้ป่วยรายที่สี่ บนสัญญาณ 4G ที่ติด ๆ ดับ ๆ กับผู้พักอาศัยที่พูดไทยสลับอังกฤษกลางประโยค — อันนั้นใช้เวลาอีกสิบเอ็ดเดือนที่เหลือ

ระยะห่างระหว่างสองสิ่งนี้แทบไม่เคยอยู่ที่ "โมเดลที่ดีกว่า" แต่อยู่ที่ทุกอย่างรอบ ๆ โมเดลต่างหาก นี่คือสิ่งที่ผมเรียนรู้ซ้ำ ๆ จากการสร้าง EasyChart เลเยอร์ AI สำหรับลงข้อมูลใน CloudNurse ซึ่งเป็น EHR ของเราสำหรับเนิร์สซิ่งโฮมและศูนย์ฟื้นฟูทั่วเอเชียตะวันออกเฉียงใต้

01 เริ่มที่เวิร์กโฟลว์ ไม่ใช่ที่โมเดล

งาน "AI" ทางคลินิกส่วนใหญ่ไม่ใช่ปัญหาการให้เหตุผลแบบปลายเปิด แต่เป็นเวิร์กโฟลว์ที่มีจุดตัดสินใจไม่กี่จุด การลงคะแนน Barthel Index ไม่ใช่ "จงสร้างสรรค์" แต่คือ "จับคู่บทสนทนานี้กับสิบช่องข้อมูลที่นิยามไว้ชัดเจน" ทันทีที่มองแบบนั้น คุณก็ควบคุมโมเดลได้ ตรวจสอบเอาต์พุตได้ และวิเคราะห์จุดที่จะพังได้จริง ใช้ agent อัตโนมัติเฉพาะตอนที่กำหนดเส้นทางล่วงหน้าไม่ได้จริง ๆ เท่านั้น — ซึ่งใน EHR เกิดขึ้นน้อยกว่าที่กระแสทำให้เชื่อ

02 โมเดลแค่เสนอ พยาบาลเป็นคนตัดสิน

ไม่มีอะไรที่ AI สร้างขึ้นควรลงไปในเวชระเบียนเอง EasyChart เขียนลง draft ไม่ใช่ตัวเวชระเบียน คนเป็นผู้ตรวจ แก้ไข แล้วจึงยืนยัน นี่ไม่ใช่แค่ลูกเล่น UX แต่คือโมเดลความปลอดภัยทั้งหมด มันทำให้มีคนรับผิดชอบทุกข้อความทางคลินิก ให้สัญญาณการแก้ไขที่สะอาดไว้เรียนรู้ต่อ และเปลี่ยน hallucination ให้เป็นแค่เรื่องน่ารำคาญที่ต้องแก้ แทนที่จะเป็นอุบัติการณ์ที่ต้องรายงาน

ค่า "BP 120/80" ที่ผิดแบบมั่นใจ อันตรายกว่าช่องว่างที่รอพยาบาลมากรอกมากนัก

03 โครงสร้างคือตัวโปรดักต์

เอาต์พุตที่มีค่าของ AI ทางคลินิกไม่ใช่ร้อยแก้ว แต่คือช่องข้อมูลที่แยกชัดและผ่านการตรวจสอบ อย่าให้โมเดลเขียนอิสระลงเวชระเบียน จงบีบให้สร้างตามสคีมา: enum สำหรับคะแนนประเมิน ช่วงค่าสำหรับสัญญาณชีพ หน่วยที่จำเป็น เมื่อโมเดลไม่มั่นใจ ช่องนั้นให้ว่างไว้และตั้งธงให้ตรวจ แทนที่จะเดาตัวเลขที่ดูสมเหตุสมผล "ว่างแต่ซื่อสัตย์" ชนะ "เต็มแต่ผิด" ทุกครั้ง

04 ออกแบบเผื่อเส้นทางที่ไม่ราบรื่นก่อน

เดโมใช้เสียงคมชัดและภาษาอังกฤษในตำราเสมอ แต่โปรดักชันคือทีวีเปิดอยู่ข้างหลัง โทรศัพท์ถือห่างเกินไป และผู้พักอาศัยพูดสลับภาษากลางประโยค จงสร้างเผื่อความจริงนั้น: fallback ไปกรอกมือได้อย่างนุ่มนวล จับข้อมูลได้บางส่วนก็เก็บไว้ และกฎเหล็กข้อเดียว — AI ทำงานแย่ลงได้ แต่ต้องไม่ขวางการดูแล ถ้าโมเดลล่ม พยาบาลก็ลงข้อมูลแบบที่เคยทำมาตลอด ฟีเจอร์ต้องเป็นส่วนเสริม ไม่งั้นก็ตัดทิ้ง

05 ปฏิบัติกับ PHI เหมือนพลูโทเนียม

คุณกำลังจัดการข้อมูลที่อ่อนไหวที่สุดอย่างหนึ่ง ภายใต้ PDPA ของไทยและความไว้ใจเงียบ ๆ ของครอบครัว นั่นกำหนดสถาปัตยกรรม ไม่ใช่แค่นโยบาย แยก tenant ให้เด็ดขาด เพื่อข้อมูลของศูนย์หนึ่งจะไม่มีวันรั่วไปอีกศูนย์ ปกปิดข้อมูลก่อนอะไรจะออกนอกขอบเขต และมี audit trail ที่บันทึกทุกข้อเสนอของ AI ว่าใครตรวจและแก้อะไร — ทั้งเพื่อ compliance และเพราะบันทึกนั้นกลายเป็นทองสำหรับการทำ eval และตัดสินใจเรื่อง retention อย่างตั้งใจ "เก็บทุกอย่างตลอดไป" คือภาระ ไม่ใช่กลยุทธ์

06 ทำ eval ก่อนเพิ่มฟีเจอร์

ก่อนผมจะเพิ่มความสามารถใด ผมอยากได้ golden set: เคสจริงที่ลบข้อมูลระบุตัวตนแล้วสองสามร้อยเคส พร้อมคำตอบที่ถูกต้อง แล้วคุณจะวัดสิ่งที่สำคัญจริงได้ — ความแม่นยำระดับช่องข้อมูล ไม่ใช่ความรู้สึก — และตั้ง regression gate ใน CI เพื่อให้การปรับ prompt ที่แอบทำคะแนน Barthel ตกไม่มีวันไปถึงผู้พักอาศัย ในวงการสุขภาพ "ดูเหมือนจะดีขึ้นตอนทดสอบ" ไม่ใช่ประโยคที่คุณอยากต้องไปแก้ต่างทีหลัง นี่คือจิตวิญญาณเดียวกับการสร้าง agent ที่ได้ผล: วัดที่ระบบ ไม่ใช่ที่ความมหัศจรรย์

07 ความหน่วงและต้นทุนคือ UX ทางคลินิก

พยาบาลจะไม่รอแปดวินาทีหน้าสัญลักษณ์หมุน ๆ เธอจะกลับไปพิมพ์เองและไม่เปิดฟีเจอร์นั้นอีก ความเร็วคือฟีเจอร์ สตรีมเอาต์พุตให้มีอะไรปรากฏทันที ใช้โมเดลที่เล็กที่สุดที่ผ่าน eval ในแต่ละขั้น — การเก็บเสียง การดึงช่องข้อมูล และการสรุป แทบไม่ต้องใช้พลังเท่ากัน แคชให้หนัก เส้นทางที่ถูกและเร็วที่สุดที่ผ่านเกณฑ์ความแม่นยำคือเส้นทางที่ถูกต้อง ใช้ความหน่วงของโมเดลใหญ่เฉพาะที่มันคุ้มเท่านั้น

08 มันคือปัญหาเชิงระบบ ไม่ใช่ปัญหาของโมเดล

เมื่อรวมทุกอย่าง บทเรียนนั้นน่าเบื่อแต่ปลดปล่อย: ส่วนที่ยากของ AI ทางคลินิกแทบไม่เกี่ยวกับตัวโมเดลเลย ขอบเขต, fallback, สถานะการตรวจทาน, audit, eval, ความหน่วง ทำสิ่งเหล่านี้ให้ถูก แล้วโมเดลขนาดกลางก็รู้สึกเหมือนเวทมนตร์ ทำพลาด แล้วต่อให้เป็นโมเดลที่ดีที่สุดบนกระดานก็ยังก่ออุบัติการณ์ จงสร้างระบบที่อยู่ข้างพยาบาล — แล้ว AI จะได้เป็นสิ่งที่อยู่เคียงข้างเธอ แทนที่จะเป็นอีกสิ่งที่ต้องคอยดูแล

AI Tech Bear
ผู้บริหารเฮลท์เทคและนักสร้างผลิตภัณฑ์ในกรุงเทพฯ ทำงานตรงจุดที่การดูแลผู้สูงอายุ ซอฟต์แวร์ และ AI มาบรรจบกัน ปัจจุบันกำลังสร้าง CloudNurse ดูผลงานเพิ่มเติม →
医疗科技生产级 AIEHR

把 AI 装进 EHR(而不弄垮生产系统)

在打造 EasyChart——CloudNurse 内部的 AI 病历记录层——过程中,我不断重温的八件事。在这里,模型每天为真实住户书写记录。

AI Tech Bear2026 年 6 月阅读 7 分钟

把一句话变成一条工整生命体征记录的演示,一个下午就能做好。而一名护士在凌晨两点、接收第四位入院者、4G 信号时断时续、住户中英文夹杂着说话时仍然信任的 AI 功能——那要花掉剩下的十一个月。

这两者之间的距离,几乎从来不在于"更好的模型",而在于模型周围的一切。以下是我在打造 EasyChart 时反复学到的——它是 CloudNurse 的 AI 记录层,而 CloudNurse 是我们面向东南亚养老院与康复中心的 EHR。

01 从工作流开始,而不是模型

大多数临床"AI"任务并非开放式推理问题,而是只有几个决策点的工作流。记录 Barthel 指数不是"发挥创意",而是"把这段对话映射到十个定义明确的字段"。一旦这样理解,你就能约束模型、校验输出,并真正分析失败之处。只有当你确实无法预先定义路径时,才动用自主 agent——而在 EHR 里,这比炒作让你以为的要少见得多。

02 模型提议,临床人员定夺

AI 产出的任何内容都不应自行进入病历。EasyChart 写入草稿,而非记录本身。由人来审阅、修改、再提交。这不是 UX 上的小讲究,而是整个安全模型。它让每一条临床主张都有人负责,给你一个干净的纠错信号用于学习,并把幻觉从需要上报的事故,变成只需修正的小麻烦。

一个自信却错误的"BP 120/80",远比一个等护士填写的空白字段更危险。

03 结构才是产品

临床 AI 有价值的输出不是散文,而是离散、经过校验的字段。所以别让模型自由书写进病历。把生成约束到你的 schema:评估分用枚举、生命体征用区间、必填单位。当模型不确定时,字段保持空白并标记待审,而不是编造一个看似合理的数字。"空白而诚实"每一次都胜过"完整却错误"。

04 先为不顺的路径设计

演示总是用清晰的音频和教科书式英语。生产环境是背景里开着的电视、举得太远的手机、说话中途切换语言的住户。要为这种现实而建:优雅地回退到手动录入、部分捕获也保留已得内容,以及一条铁律——AI 可以降级,但绝不能阻碍照护。模型宕机时,护士照旧按一贯方式记录。功能要么是加分项,要么就该拿掉。

05 像对待钚一样对待 PHI

你处理的是最敏感的数据之一,受泰国 PDPA 约束,也承载着家属无声的信任。这决定的是架构,而不仅是政策。严格的租户隔离,让一家机构的数据绝不会渗入另一家。任何数据越过边界前先脱敏。一条审计轨迹,记录每一个 AI 建议、谁审阅了它、改了什么——既为合规,也因为这份记录正是做评估的金矿。并且有意地决定保留期;"永远全部保留"是负债,不是策略。

06 先做评估,再加功能

在增加任何能力之前,我想要一个 golden set:几百个真实、去标识化、且已知正确字段的就诊记录。然后你就能衡量真正要紧的东西——字段级准确度,而非感觉——并在 CI 里设一道回归闸,让某次悄悄拉低 Barthel 评分的 prompt 改动永远到不了住户面前。在医疗里,"测试时似乎更好"不是你日后想去辩护的句子。这和打造高效 agent 是同一种精神:衡量系统,而非衡量魔法。

07 延迟与成本就是临床 UX

护士不会盯着转圈等八秒;她会回去自己打字,再也不打开这个功能。速度就是功能。流式输出,让东西立刻出现。每一步都用能通过你评估的最小模型——语音清理、字段抽取、摘要,很少需要同等算力。大力缓存。能过你准确度门槛、又最便宜最快的路径,就是对的路径;只在大模型值得时,才花它那份延迟。

08 这是系统问题,不是模型问题

合起来看,这个教训既无聊又令人释然:临床 AI 难的部分,几乎都与模型无关。边界、回退、审阅状态、审计、评估、延迟。把这些做对,一个中等模型也像魔法。做错了,排行榜上最好的模型照样酿成事故。去打造那个为护士兜底的系统——这样 AI 才能成为她身边的依靠,而不是又一件要照看的东西。

AI Tech Bear
驻曼谷的医疗科技高管与产品打造者,工作于长者照护、软件与 AI 的交汇处。目前正在打造 CloudNurse。查看更多作品 →
ヘルステック本番 AIEHR

EHR の中に AI を載せる(本番を壊さずに)

EasyChart——CloudNurse 内部の AI カルテ記録レイヤー——を作りながら、何度も学び直している 8 つのこと。ここではモデルが毎日、実在の入居者の記録を書いています。

AI Tech Bear2026年6月7分で読める

話した一文をきれいなバイタル記録に変えるデモは、一日でできます。けれど、午前 2 時、4 人目の入院対応中、不安定な 4G 回線で、タイ語と英語を文の途中で切り替える入居者を相手に、看護師が信頼できる AI 機能——それには残りの 11 か月がかかります。

この二つの差は、ほとんどの場合「より良いモデル」ではありません。モデルの周りのすべてです。これは、東南アジアの介護施設・リハビリ施設向け EHR である CloudNurse の AI 記録レイヤー、EasyChart を作りながら私が何度も学び直していることです。

01 モデルではなく、ワークフローから始める

臨床の「AI」タスクの多くは、オープンエンドな推論問題ではなく、判断点がいくつかあるだけのワークフローです。Barthel 指数を記録するのは「創造性を発揮せよ」ではなく「この会話を、明確に定義された 10 個のフィールドに対応づけよ」です。そう捉えた瞬間、モデルを制約し、出力を検証し、失敗を本当に分析できるようになります。自律エージェントに頼るのは、経路を事前に定義できない場合だけ——EHR の中では、話題ほど多くはありません。

02 モデルは提案し、臨床者が決める

AI が生み出すものは、何ひとつ自動でカルテに入ってはいけません。EasyChart は記録そのものではなく、下書きに書き込みます。人がレビューし、修正し、確定します。これは UX の気配りではなく、安全モデルそのものです。すべての臨床的主張に責任者を残し、学習用のきれいな修正シグナルを与え、ハルシネーションを報告すべきインシデントではなく、直せばよい厄介事に変えます。

自信たっぷりに間違った「BP 120/80」は、看護師の入力を待つ空欄よりはるかに危険です。

03 構造こそがプロダクト

臨床 AI の価値ある出力は文章ではなく、離散的で検証済みのフィールドです。だからモデルにカルテへ自由に書かせてはいけません。生成をスキーマに制約します:評価点は列挙型、バイタルは範囲、単位は必須。モデルが不確かなときは、もっともらしい数字をでっち上げず、フィールドを空のままレビュー対象として印を付けます。「空で正直」は、毎回「埋まっていて間違い」に勝ります。

04 まず、うまくいかない経路を設計する

デモは常にクリーンな音声と教科書的な英語です。本番は、背後のテレビ、遠すぎる位置のスマホ、文の途中で言語を切り替える入居者です。その現実のために作ります:手入力への穏やかなフォールバック、取れた分だけ保持する部分取り込み、そして一つの鉄則——AI は劣化してよいが、ケアを止めてはならない。モデルが落ちても、看護師はいつも通りに記録します。機能は付加的であるか、さもなければ消えるかです。

05 PHI はプルトニウムのように扱う

あなたが扱うのは最も機微なデータの一つで、タイの PDPA と、ご家族の静かな信頼の下にあります。それは方針だけでなく、アーキテクチャを決めます。厳格なテナント分離で、ある施設のデータが別の施設へ漏れることを決して許さない。境界を越える前に秘匿化する。すべての AI 提案、誰がレビューし、何を変えたかを記録する監査ログ——コンプライアンスのため、そしてその記録が評価の宝になるからです。そして保持期間は意図的に決める。「すべてを永遠に保持」は戦略ではなく負債です。

06 機能の前に評価を

能力を追加する前に、ゴールデンセットが欲しい——数百件の、実在の、識別情報を除いた、正解フィールドが分かっている受診記録。そうすれば本当に重要なもの——雰囲気ではなくフィールド単位の正確さ——を測れ、CI に回帰ゲートを置いて、Barthel スコアをこっそり悪化させるプロンプト変更が入居者に届かないようにできます。医療では「テストでは良さそうだった」は、後で弁明したい一文ではありません。これは効果的なエージェントを作るのと同じ精神です:魔法ではなく、システムを測る。

07 レイテンシとコストは臨床 UX

看護師はスピナーの前で 8 秒も待ちません。自分で打ち直し、二度とその機能を開きません。速度は機能です。出力をストリーミングして、すぐに何かが現れるようにします。各ステップで評価を通る最小のモデルを使う——音声整形、フィールド抽出、要約に同じ馬力はめったに要りません。積極的にキャッシュします。正確さの基準を満たす中で最も安く速い経路が正解で、大きなモデルのレイテンシは、それに見合う場所でだけ使います。

08 これはモデルの問題ではなく、システムの問題

まとめると、その教訓は退屈で、そして解放的です:臨床 AI の難所は、ほとんどモデルとは関係ありません。境界、フォールバック、レビュー状態、監査、評価、レイテンシ。これらを正しくすれば、中堅のモデルでも魔法のように感じます。間違えれば、リーダーボード最強のモデルでもインシデントを起こします。看護師を支えるシステムを作る——そうすれば AI は、もう一つの世話の種ではなく、彼女のそばで支える存在になれます。

AI Tech Bear
バンコクを拠点とするヘルステックの経営者でありプロダクトの作り手。高齢者ケア・ソフトウェア・AI が交わる場所で働いています。現在は CloudNurse を開発中。ほかの実績を見る →
醫療科技生產級 AIEHR

把 AI 裝進 EHR(而不弄垮生產系統)

在打造 EasyChart——CloudNurse 內部的 AI 病歷記錄層——過程中,我不斷重溫的八件事。在這裡,模型每天為真實住民書寫記錄。

AI Tech Bear2026 年 6 月閱讀 7 分鐘

把一句話變成一條工整生命徵象記錄的示範,一個下午就能做好。而一名護理師在凌晨兩點、接收第四位入院者、4G 訊號時斷時續、住民中英文夾雜著說話時仍然信任的 AI 功能——那要花掉剩下的十一個月。

這兩者之間的距離,幾乎從來不在於「更好的模型」,而在於模型周圍的一切。以下是我在打造 EasyChart 時反覆學到的——它是 CloudNurse 的 AI 記錄層,而 CloudNurse 是我們面向東南亞安養機構與復健中心的 EHR。

01 從工作流開始,而不是模型

大多數臨床「AI」任務並非開放式推理問題,而是只有幾個決策點的工作流。記錄 Barthel 指數不是「發揮創意」,而是「把這段對話對應到十個定義明確的欄位」。一旦這樣理解,你就能約束模型、驗證輸出,並真正分析失敗之處。只有當你確實無法預先定義路徑時,才動用自主 agent——而在 EHR 裡,這比炒作讓你以為的要少見得多。

02 模型提議,臨床人員定奪

AI 產出的任何內容都不應自行進入病歷。EasyChart 寫入草稿,而非記錄本身。由人來審閱、修改、再提交。這不是 UX 上的小講究,而是整個安全模型。它讓每一條臨床主張都有人負責,給你一個乾淨的糾錯訊號用於學習,並把幻覺從需要通報的事故,變成只需修正的小麻煩。

一個自信卻錯誤的「BP 120/80」,遠比一個等護理師填寫的空白欄位更危險。

03 結構才是產品

臨床 AI 有價值的輸出不是散文,而是離散、經過驗證的欄位。所以別讓模型自由書寫進病歷。把生成約束到你的 schema:評估分用列舉、生命徵象用區間、必填單位。當模型不確定時,欄位保持空白並標記待審,而不是編造一個看似合理的數字。「空白而誠實」每一次都勝過「完整卻錯誤」。

04 先為不順的路徑設計

示範總是用清晰的音訊和教科書式英語。生產環境是背景裡開著的電視、舉得太遠的手機、說話中途切換語言的住民。要為這種現實而建:優雅地回退到手動輸入、部分擷取也保留已得內容,以及一條鐵律——AI 可以降級,但絕不能阻礙照護。模型當機時,護理師照舊按一貫方式記錄。功能要麼是加分項,要麼就該拿掉。

05 像對待鈽一樣對待 PHI

你處理的是最敏感的資料之一,受泰國 PDPA 約束,也承載著家屬無聲的信任。這決定的是架構,而不僅是政策。嚴格的租戶隔離,讓一家機構的資料絕不會滲入另一家。任何資料越過邊界前先去識別化。一條稽核軌跡,記錄每一個 AI 建議、誰審閱了它、改了什麼——既為合規,也因為這份記錄正是做評估的金礦。並且有意地決定保留期;「永遠全部保留」是負債,不是策略。

06 先做評估,再加功能

在增加任何能力之前,我想要一個 golden set:幾百個真實、去識別化、且已知正確欄位的就診記錄。然後你就能衡量真正要緊的東西——欄位級準確度,而非感覺——並在 CI 裡設一道回歸閘,讓某次悄悄拉低 Barthel 評分的 prompt 改動永遠到不了住民面前。在醫療裡,「測試時似乎更好」不是你日後想去辯護的句子。這和打造高效 agent 是同一種精神:衡量系統,而非衡量魔法。

07 延遲與成本就是臨床 UX

護理師不會盯著轉圈等八秒;她會回去自己打字,再也不打開這個功能。速度就是功能。串流輸出,讓東西立刻出現。每一步都用能通過你評估的最小模型——語音清理、欄位擷取、摘要,很少需要同等算力。大力快取。能過你準確度門檻、又最便宜最快的路徑,就是對的路徑;只在大模型值得時,才花它那份延遲。

08 這是系統問題,不是模型問題

合起來看,這個教訓既無聊又令人釋然:臨床 AI 難的部分,幾乎都與模型無關。邊界、回退、審閱狀態、稽核、評估、延遲。把這些做對,一個中等模型也像魔法。做錯了,排行榜上最好的模型照樣釀成事故。去打造那個為護理師兜底的系統——這樣 AI 才能成為她身邊的依靠,而不是又一件要照看的東西。

AI Tech Bear
駐曼谷的醫療科技高階主管與產品打造者,工作於長者照護、軟體與 AI 的交會處。目前正在打造 CloudNurse。查看更多作品 →