مرحله ۰۱شناسایی و اسکن پکخواندن شناسهٔ پک و ثبت نقطهٔ ورود آن به جریان رهگیری.
استانداردها، قبل از طراحی و خرید
مدل شناسه، کیفیت DPM و بازفرآوری باید از ابتدا به مرجع درست متصل باشند؛ نسخهٔ نهایی هر الزام در تحلیل انطباق بیمارستان تأیید می‌شود.
GS1 DataMatrix / Healthcareساختار شناسه و حامل دوبعدی برای اقلام سلامت و DPM ابزارهای کوچک.مشاهده مرجع GS1 ↗ISO/IEC 29158:2025روش سنجش کیفیت نماد Direct Part Mark و شرایط تصویربرداری/نور.مشاهده مرجع ISO ↗ISO 17664-1:2021اطلاعات سازنده برای پردازش و بازپردازش ابزارهای بحرانی و نیمه‌بحرانی.مشاهده مرجع ISO ↗ISO 15883 / چرخه CSSDمرجع خانوادهٔ الزامات Washer-disinfector؛ کنترل استریل و SOP جداگانه اعتبارسنجی می‌شود.مشاهده مرجع ISO ↗
۰۱ · معرفی
ابزار درست، در پک درست؛ با سابقهٔ روشن هر تحویل.
راهکار کدینگ و رهگیری ابزار جراحی برای شناسایی ابزار، کنترل محتویات پک و ثبت مسیر تحویل—متناسب با گردش واقعی CSSD و اتاق عمل هر بیمارستان.
محور فعلی: کدینگ و رهگیریمدل اجرا: اختصاصی هر بیمارستاناستقرار: محلی و قابل توسعه
یک سامانهٔ خارجی آماده برای کپی‌کردن نیست.
هسته و استانداردها مشترک می‌مانند؛ مسیر پک، نقش‌ها، تجهیزات، زیرساخت و گزارش‌ها برای هر بیمارستان تنظیم می‌شوند.
هسته و استانداردها مشترک می‌مانند؛ مسیر پک، نقش‌ها، تجهیزات، زیرساخت و گزارش‌ها برای هر بیمارستان تنظیم می‌شوند.
نمایش اجرای واقعی
۳ مرحله · هر ویدیو ۱۰ ثانیهمراحل انجام کدینگ، از ۱ تا ۳
سه ویدیوی کوتاه زیر، توالی اجرای کار را به‌ترتیب نشان می‌دهند. برای مشاهده هر مرحله، پخش همان کارت را انتخاب کنید.
مرحله ۰۲ثبت ابزار در سامانهشناسایی ابزار و تخصیص آن به ست تعریف‌شده در ایستگاه کاری.
مرحله ۰۳کنترل نهایی سبد ابزاراسکن و تطبیق نهایی محتویات برای تکمیل سابقهٔ قابل رهگیری.
۰۲ · مسئلهٔ امروز
وقتی هویت ابزار و تحویل‌ها روشن نیست، هزینه فقط «یک ابزار گم‌شده» نیست.
جست‌وجو، بازکردن پک اضافه، وابستگی به حافظه افراد، مغایرت پک، دوباره‌کاری و نداشتن سابقهٔ قابل اتکا همه روی ظرفیت CSSD و اتاق عمل اثر می‌گذارند.
01
ابزار کم، اضافه یا اشتباه در پکمغایرتی که ممکن است تا لحظهٔ نیاز در اتاق عمل دیده نشود.
02
جست‌وجوی زمان‌بر برای ابزار مفقودوقتی آخرین مشاهده و آخرین تحویل به‌صورت ساختاریافته ثبت نشده باشد.
03
وابستگی شدید به نیروی باتجربهتشخیص ابزار و ترتیب پک‌کردن نباید فقط در حافظهٔ افراد باشد.
04
دادهٔ ناکافی برای تصمیم مدیریتیبدون سابقهٔ معتبر، هزینه، زمان و منشأ تکرار خطا قابل اندازه‌گیری نیست.
هدف
هر ابزار یک هویت، هر پک یک نسخه، هر تحویل یک رویداد.
هدف، تبدیل زنجیره‌ای پراکنده از تجربهٔ فردی و ثبت دستی به جریان قابل مشاهده و قابل بازبینی است.
۰۳ · سابقهٔ جهانی
اصل رهگیری ابزار و ست، یک نظریهٔ تازه نیست.
نمونه‌های بین‌المللی نشان می‌دهند که رهگیری و استانداردسازی در CSSD و اتاق عمل سال‌هاست اجرا می‌شود. نتایج زیر متعلق به همان مراکز و همان پروژه‌هاست؛ نه وعدهٔ نتیجه برای بیمارستان ایرانی.
بریتانیا · Dorset County Hospital
۱۹ → ۱۲ ساعت
زمان گردش ست در گزارش بیمارستان پس از استفاده از دادهٔ تولید و سپس قابلیت Fast Track کاهش یافته است.
منبع: Getinge / T-DOC customer case. گزارش فروشنده؛ نتیجهٔ مشترک نرم‌افزار و تغییر فرایند.
بریتانیا · Leeds Teaching Hospitals
£83,548.41
صرفه‌جویی گزارش‌شده از استانداردسازی و عقلانی‌سازی اقلام سینی‌های پنج عمل رایج در یک دورهٔ شش‌ماهه.
منبع: NHS Scan4Safety. این عدد اثر مستقل کدینگ تک‌ابزار نیست.
ایرلند · HSE Central Decontamination Units
رهگیری استانداردشده
GS1 استفاده از شناسه و بارکد را برای رهگیری سینی‌های ابزار در واحدهای آلودگی‌زدایی مرکزی HSE مستند کرده است.
منبع: GS1 Ireland. شاهد وجود و مقیاس‌پذیری مدل رهگیری؛ نه تأیید محصول ما.
مرز ادعا: این تجربه‌ها نشان می‌دهند مسئله و خانوادهٔ راهکار در جهان واقعی هستند. عملکرد، هزینه و نتیجهٔ سامانهٔ پیشنهادی ما باید در دامنهٔ واقعی هر بیمارستان جداگانه آزموده و پذیرفته شود.
۰۴ · راهکار هسته
سه موجودیت را یکی نمی‌کنیم: وسیله، پک و لایهٔ رهگیری هرکدام هویت مستقل دارند.
یک قیچی «پک» نیست. ابزار تکی با شناسهٔ خودش رهگیری می‌شود؛ پک یک مجموعهٔ نسخه‌دار است که می‌تواند به‌صورت پارچه‌ای یا داخل کانتینر فلزی استریل شود؛ و تگ/گیت یک لایهٔ جدا برای رهگیری جابه‌جایی پک است.
قاعدهٔ SITE-10B: Instrument ID، Pack ID و Tracking Tag ID سه شناسهٔ متفاوت‌اند. «آخرین مشاهدهٔ تک‌ابزار» با «موقعیت پک در Zone/Gate» و «مکان لحظه‌ای RTLS» یک ادعا نیست.
Instrument = قلم منفردPack/Set = مجموعهٔ ابزارWrapped Pack = فرم پارچه‌ایRigid Container = فرم کانتینریTag = لایهٔ رهگیری پک
وسیلهٔ تکی · Instrument
هر قلم مانند قیچی، پنس یا کلمپ یک جسم مستقل با سابقهٔ مستقل است.
شناسهDPM / Serial / Registry
سابقهمشاهده، تعمیر، وضعیت، عضویت در پک
مکانآخرین Observation معتبر
پک / ست · Pack / Set
یک مجموعهٔ نسخه‌دار از ابزارها با نام، محتوا، وضعیت و گردش مستقل.
شناسهPack ID مستقل
سابقهمحتوا، نسخه، تحویل، استریل، استفاده
کنترلکمبود / اضافه / عضو اشتباه
فرم فیزیکی پک
پک می‌تواند با wrap استریل بسته شود یا داخل rigid sterilization container قرار بگیرد.
مدل AWrapped / Soft Pack
مدل BRigid Container
وضعیتنوع بسته‌بندی در رویداد پک ثبت می‌شود
تگ و رهگیری پک · Tag
لایهٔ اختیاری برای تشخیص عبور، Zone و کنترل خروج؛ جدا از DPM تک‌ابزار.
فناوریBarcode / RFID / EAS / RTLS
کاربردZone, Gate, Inventory, Alert
مرزRTLS واقعی نیازمند زیرساخت جداست
پک پارچه‌ای / Wrapped Set
ست ابزار پس از آماده‌سازی با سیستم wrap سازگار بسته می‌شود و Pack ID روی بسته همراه چرخه حرکت می‌کند.
- شناسهٔ پک جدا از شناسهٔ ابزارها
- ثبت نوع بسته‌بندی و نسخهٔ محتوا
- در صورت استفاده از تگ پارچه‌ای/برچسب، سازگاری با فرایند باید آزموده شود
کانتینر فلزی / Rigid Sterilization Container
ست داخل کانتینر استریل سازگار قرار می‌گیرد؛ Pack ID، Container ID و در صورت نیاز RFID می‌توانند جدا ثبت شوند.
- هویت ظرف می‌تواند مستقل از Pack ID باشد
- ارتباط Pack ↔ Container تاریخ‌دار و قابل audit است
- تگ on-metal/autoclavable نیازمند انتخاب و validation مستقل است
معماری هویت: از قلم منفرد تا رهگیری پک
Instrument IDs × Nهویت تک‌ابزار و آخرین مشاهدهٔ مستقیم
←
Pack ID + Master Pack Versionمجموعه، تعداد و قواعد عضویت
←
Wrap / Containerفرم فیزیکی و Container ID در صورت وجود
←
Tag + Event StreamRFID/Barcode/Gate/Zone حسب طراحی بیمارستان
LEVEL 1تک‌ابزار
آخرین اسکن/Observation معتبر را نشان می‌دهیم؛ ادعای مکان لحظه‌ای از DataMatrix نداریم.
LEVEL 2پک و Zone
با Scan یا RFID/Gate می‌توان آخرین Zone یا عبور ثبت‌شدهٔ Pack را نشان داد.
LEVEL 3RTLS لحظه‌ای
برای موقعیت لحظه‌ای‌تر، BLE/UWB/RTLS یا زیرساخت معادل باید جدا طراحی و اعتبارسنجی شود.
Instrument → هویت تک‌قلمPack → مجموعهٔ نسخه‌دارPackaging → Wrap یا Rigid ContainerTracking → Scan / RFID / Gate / RTLS
مبنای مفهومی بسته‌بندی: CDC توضیح می‌دهد اقلام پس از تمیزکردن، خشک‌کردن و بازرسی می‌توانند wrap شوند یا داخل rigid container قرار گیرند. فناوری رهگیری پک باید جدا از الزامات استریلیزاسیون و IFU ظرف/بسته انتخاب شود. CDC · Sterilizing Practices
نمای قبلی اثبات DPM و رجیستر تک‌ابزار حفظ شده است؛ از اینجا به بعد فقط دربارهٔ Instrument-level identification صحبت می‌کند، نه خود Pack.
۱
شناسایی نمونهٔ ابزار
کد خوانده می‌شود و فقط در صورت تطبیق معتبر با رجیستر، نمونه پذیرفته می‌شود.
۲
تطبیق با نسخهٔ پک
سیستم می‌داند این پک دقیقاً به چه اقلامی و با چه قواعدی نیاز دارد.
۳
ثبت رویداد و مسئول
تحویل، پذیرش، مغایرت و تغییر وضعیت به‌صورت رویداد قابل بازیابی ثبت می‌شوند.
۴
بازخورد روشن
کاربر باید بداند اسکن فقط خوانده شده، در انتظار است یا واقعاً ثبت و پذیرفته شده است.
۰۵ · گردش یک پک
یک Pack Journey، با دو فرم فیزیکی: پارچه‌ای یا کانتینر فلزی.
در تمام چرخه، هویت «پک» ثابت می‌ماند؛ فرم فیزیکی آن می‌تواند Wrap یا Rigid Container باشد. ابزارهای داخل آن در مرحلهٔ بازرسی/مونتاژ با هویت تک‌قلم کنترل می‌شوند.
مرز مهم: برای تک‌ابزار، این دمو «آخرین مشاهدهٔ معتبر» را نشان می‌دهد. برای Pack می‌توان لایهٔ جداگانهٔ Scan/RFID/Zone Tracking اضافه کرد؛ مکان لحظه‌ای دقیق فقط با RTLS مناسب و زیرساخت تأییدشده ادعا می‌شود.
A · آلوده / تحویلایستگاه A · تحویل و بازگشت
ورودیپک برگشتی، تحویل‌دهنده، گیرنده و مغایرت قابل مشاهده
عملثبت تحویل و اتصال پک به دسته کاری بعدی
خروجیرویداد قابل پیگیری؛ بدون ادعای شناسایی تک‌ابزار آلوده
B · کنترل مرحلهایستگاه B · کنترل عبور مرحله
ورودیدسته شست‌وشو و وضعیت عبور از فرایند تعریف‌شده
عملثبت checkpoint و تحویل به ناحیه تمیز
خروجیمرز روشن بین مرحله قبلی و بازرسی/مونتاژ
C · بازرسی / پکایستگاه C · شناسایی و پک‌بندی
ورودیابزار تمیز و خشک + نسخه معتبر قالب پک
عملشناسایی، تطبیق تعداد و نوع، حل استثنا
خروجیپک قابل بستن یا مغایرت آشکار و قابل رسیدگی
۰۶ · کنترل خطا
روی سناریوهای خطا بزنید و ببینید سیستم قرار است چه چیزی را متوقف یا آشکار کند.
این شبیه‌ساز نمایشی است؛ هدف آن توضیح منطق کنترل است، نه ادعای اینکه نتیجهٔ عملکرد محصول روی ابزار واقعی از قبل اثبات شده است.
پک نمایشی ORTHO-SET / نسخه 3
بستن پک متوقفنمایش منطقی · دادهٔ ساختگی برای پروپوزال
پک کامل اعلام نشودکمبود ثبت شودآخرین مشاهده بررسی شود
اصل کنترل: سامانه نباید برای کامل نشان‌دادن روند، هویت یا رویداد نامطمئن را حدس بزند. No-read، قلم ناشناخته و گسست تحویل باید به‌صورت استثنا باقی بمانند.
۰۷ · پیدا‌کردن ابزار
وقتی یک ابزار پیدا نمی‌شود، «آخرین مشاهدهٔ معتبر» و نقطهٔ گسست را به مدیر نشان بدهید.
این مدل رویدادمحور است: می‌گوید چه چیزی واقعاً ثبت شده و از کجا به بعد مشاهده مستقیم نداریم؛ مکان زنده یا تقصیر فرد را از داده ناقص نتیجه نمی‌گیرد.
نمونهٔ جست‌وجو: Instrument D-114
Trace mode · event-basedشناسه و زمان‌ها نمایشی هستند
08:14پک به اتاق عمل تحویل شد
09:03پک برای مورد جراحی باز شد
10:21پک برگشتی در A ثبت شد
10:32آخرین مشاهدهٔ مستقیم ابزار
بعد از 10:32برای خود ابزار ثبت مستقیم نداریم
پاسخ قابل دفاع به کاربر
آخرین مشاهدهٔ معتبر این ابزار ساعت ۱۰:۳۲ در مرحلهٔ بازرسی ثبت شده است. بعد از آن رویدادهای مربوط به پک وجود دارند، اما مشاهدهٔ مستقیم دیگری برای خود ابزار ثبت نشده است. بنابراین بررسی باید از نقاط بعد از این مشاهده و مسیر همان پک آغاز شود.
«آخرین مشاهده» ≠ «مکان فعلی قطعی» ≠ «آخرین تحویل‌گیرنده مقصر است»
ترتیب پیشنهادی بررسی
1ایستگاه بازرسی و محدودهٔ کاری همان session
2پک، ظرف انتقال و مسیر بعد از checkpoint ثبت‌شده
3استثناها، مغایرت‌ها و تحویل‌های ناقص همان بازه
هر انتقال: فرستنده→ گیرنده→ زمان→ وضعیت پذیرش→ پک/مرحله→ سابقه قابل جست‌وجو
۰۸ · سفارشی‌سازی بیمارستان
هسته مشترک؛ اجرای اختصاصی بر اساس واقعیت بیمارستان شما.
هدف این نیست که یک نرم‌افزار خارجی را بدون شناخت فرایند روی بیمارستان قرار دهیم. ابتدا مدل فعلی شما فهمیده و سپس پیکربندی و دامنهٔ اجرا تعیین می‌شود.
پک‌ها و ابزارهای واقعینام‌ها، نسخهٔ پک، جایگزین‌ها، اقلام بحرانی و شناسه‌های موجود
گردش CSSD و اتاق عملنقاط تحویل، نقش‌ها، مسیر آلوده/تمیز و استثناها
زیرساخت و محدودیت‌های ایرانشبکه، سرور، تأمین قطعه، مجوز نرم‌افزار و پشتیبانی
قواعد مدیریتی بیمارستانگزارش‌ها، سطح دسترسی، مسئول پذیرش و سیاست‌های داخلی
←
خروجی شناخت
پروفایل اجرایی اختصاصی بیمارستان
نقشهٔ وضع موجود، دامنهٔ هسته، نقاط اسکن، تجهیزات، مسئولیت‌ها، استثناها، نیاز اتصال و معیار پذیرش قبل از استقرار مشخص می‌شوند.
شناختپیکربندیآزمونآموزشپذیرش
۰۹ · کاربر و آموزش
آموزش کنار کار؛ از محتوای تأییدشده، نه از حدس.
کدینگ می‌تواند شناخت ابزار و ترتیب پک را از حافظهٔ فردی جدا کند. ماژول آموزش اختیاری است و محتوای واقعی آن باید از IFU، SOP و مسئولان مجاز همان بیمارستان بیاید.
مرز این دمو: هیچ دستور شست‌وشو، زمان، ماده، دما یا روش بازفرآوری برای ابزار واقعی در این صفحه ساخته نشده است. تا وقتی سند تأییدشده برای همان ابزار/خانواده ثبت نشده باشد، سامانه باید «منبع تأییدشده موجود نیست» نشان دهد.
نمونهٔ نمایشی، نه ابزار واقعیپروفایل آموزشی نمونه
ابزار انتخاب‌شده در ایستگاه C
پس از خواندن شناسه و resolve در رجیستر، کاربر می‌تواند محتوای مرتبط با همان instance یا خانواده را ببیند.
هویت از Registryقالب پک نسخه‌دارراهنمای واقعی هنوز وارد نشده
شناخت مبتنی بر رجیستر
نام و تصویر باید به شناسهٔ معتبر وصل باشند.
کاربر ابتدا نتیجهٔ resolve رجیستر را می‌بیند؛ تصویر و نام فقط برای کمک به تشخیص و کنترل انسانی نمایش داده می‌شوند. این صفحه نمونه است و هویت پزشکی واقعی تولید نمی‌کند.
منبع: Registry / Master data بیمارستان · در دمو فقط ساختار نمایش داده می‌شود.
نمونهٔ دستیار متنی؛ کانال صوتی می‌تواند بعداً روی همین پاسخ‌ها قرار بگیرد
یک سؤال نمونه را انتخاب کنید. پاسخ این دمو deterministic است و اتصال AI زنده ندارد.
◉ ورودی صوتی = گزینهٔ آینده؛ این فایل برای کارکرد خود به میکروفن یا اینترنت وابسته نیست.۱۰ · زیرساخت و خدمات
قبل از قیمت، توپولوژی، ظرفیت و چیزهایی که بیمارستان از قبل دارد را روشن می‌کنیم.
سه نقش منطقی A/B/C نقطهٔ شروع طراحی‌اند؛ اما تعداد واقعی تجهیزات، سرور، شبکه، پشتیبان و اتصال‌ها با حجم کار و امکانات همان بیمارستان تعیین می‌شود.
اتاق عمل و CSSDپک، ابزار، تحویل، استثنا و جریان واقعی بیمارستان
←
سه نقش عملیاتی پایه
A · تحویل/بازگشتB · کنترل عبور مرحلهC · بازرسی/پک‌بندی
سه نقش الزاماً سه تجهیز یکسان نیستند؛ ظرفیت و محل نصب جدا سنجیده می‌شود.←
هستهٔ محلی ثبت و رهگیریرجیستر هویت، نسخهٔ پک، رویدادها، کاربران، گزارش و صف استثنا
local-firstaudit trailrestore
←
IT و اتصال‌های اختیاریشبکه، پشتیبان، برق پایدار، HIS/OR و کنترل خروج فقط در دامنهٔ توافق‌شده
اصل طراحی: اجرای هسته نباید بی‌دلیل به اینترنت عمومی یا سرویس ابری decoder وابسته باشد. وضعیت تأمین قطعه، مجوز نرم‌افزار، پشتیبانی و امکان بازیابی نیز بخشی از طراحی بیمارستان است.
چک‌لیست هزینه‌دار زیرساخت همان بیمارستان
هشدار مهم: این قیمت‌ها واقعی یا قراردادی نیستند.اعداد زیر یک مثال برنامه‌ریزی با تقریب زیاد و برحسب میلیون تومان‌اند. برای واقع‌گرایی نسبی، تجهیزات DPM، سرور، UPS، شبکه، نرم‌افزار و خدمات در سطح بازار ۱۴۰۵ در نظر گرفته شده‌اند؛ اما نرخ ارز، برند، گارانتی، دامنهٔ اتصال و وضعیت موجود بیمارستان می‌تواند نتیجه را شدیداً تغییر دهد. مبلغ قابل اتکا فقط پس از بازدید و RFQ روز ساخته می‌شود.
هر وضعیت را تغییر دهید و تعداد/هزینهٔ واحد را وارد کنید. فقط «نیازمند تأمین» و «نیازمند اصلاح» وارد جمع می‌شوند.
سناریوی نمونه فعالایستگاه A · تحویل و بازگشتمحل، فضای کار، خواندن شناسهٔ پک و ثبت تحویل
هزینه منظورشده۰
ایستگاه B · کنترل عبورمرز مرحله و ثبت checkpoint پس از فرایند تعریف‌شده
هزینه منظورشده۰
ایستگاه C · شناسایی و مونتاژرید DPM/شناسه، نمایش الگوی پک و کنترل مغایرت
هزینه منظورشده۰
هستهٔ محلی نرم‌افزار و دادهمحل اجرا، نسخه، دسترسی، لاگ و ظرفیت ذخیره
هزینه منظورشده۰
شبکه و سیاست امنیتیLAN/VLAN، حساب‌ها، دسترسی‌ها و حالت قطع ارتباط
هزینه منظورشده۰
پشتیبان و بازیابیbackup، restore test، نگهداری و مسئول انجام
هزینه منظورشده۰
برق، UPS و محیط نصببرق پایدار، کابل، نظافت‌پذیری، فضا و شرایط ایستگاه
هزینه منظورشده۰
قطعه یدکی و پشتیبانیمدل تأمین، lead time، جایگزین qualified و مسئول سرویس
هزینه منظورشده۰
اتصال HIS/OR یا سامانه دیگراختیاری؛ فقط در صورت نیاز و توافق دامنه و امنیت
هزینه منظورشده۰
موارد تعیین‌وضعیت‌شده۹ / ۹
۹۵۰نیازمند تأمین · میلیون تومان
۲۹۰نیازمند اصلاح · میلیون تومان
۱٬۲۴۰جمع پایه · میلیون تومان
۱٬۴۲۶برآورد با ذخیره احتیاطی · میلیون تومان
راهنمای عدد: قیمت‌های عمومی بازار فقط کنترل مرتبهٔ بزرگی‌اند؛ هزینهٔ reader تخصصی DPM، یکپارچه‌سازی و خدمات بدون مشخصات فنی و RFQ قطعی نیست.
برآورد اولیه ظرفیت ایستگاه C
این محاسبه فقط «زمان خام اسکن تک‌ابزار» را می‌سنجد؛ handling، چرخاندن ابزار، خطا، exception، نظافت و صف پیک جدا هستند.
مثال فرضی P0، نه داده بیمارستان
قابل تغییر
مثال فرضی P0
فرض برنامه‌ریزی؛ قابل تغییر
٪ — فقط برای سناریو
A/B و کل handling جدا هستند
۶٬۰۰۰ابزار/روز در این مثال
۵٫۰ساعت خام اسکن/روز
۵٫۶ساعت مؤثر هر lane در فرض فعلی
۱lane محاسباتی C فقط برای اسکن خام
عدد lane، تعداد کل ایستگاه‌های پروژه نیست. A و B نقش‌های جدا دارند و ظرفیت واقعی C بعد از اندازه‌گیری handling، خطاها و پیک کاری تعیین می‌شود.
موجودی و throughputپک/روز، ابزار/پک، شیفت و پیک کاری
تجهیزات موجودPC، reader، شبکه، سرور، UPS و چاپ/برچسب حسب طراحی
تداوم خدمتbackup/restore، قطعه یدکی، پشتیبانی و حالت offline
اتصال‌هاHIS/OR، کنترل خروج و سایر سامانه‌ها فقط در scope مصوب
۱۱ · مدل مالی بیمارستان
هزینهٔ اولیه، هزینهٔ ماهانه و منفعت را با دادهٔ خود بیمارستان کنار هم می‌گذاریم.
این ماشین‌حساب قیمت یا صرفه‌جویی را حدس نمی‌زند. خانهٔ خالی یعنی «نامعلوم»؛ صفر فقط وقتی وارد شود که واقعاً صفر تأییدشده باشد.
پروفایل سناریوی بیمارستاناین مدل مربوط به کدام بیمارستان یا جلسه است؟
فقط اطلاعات عملیاتی/تجاری غیرحساس وارد کنید. اطلاعات بیمار، نام فرد درمان‌شونده یا دادهٔ محرمانه وارد نکنید.
این فایل فقط برای ارائهٔ عمومی است.
سناریوی نمونه بیمارستان متوسط — قابل ویرایش، نیازمند اعتبارسنجی و RFQفرض برنامه‌ریزی: ۱۰۰ پک در روز، میانگین ۶۰ ابزار در هر پک و سه ایستگاه. این اعداد قیمت قرارداد یا نتیجه تضمین‌شده نیستند.
سناریوی نمونه فعال۱ · خط مبنای نقدی ماهانهرویداد × هزینه مستقیم همان رویداد
میلیون تومانارزش کل موجودی به‌خودی‌خود «صرفه‌جویی» نیست. منفعت نقدی فقط از هزینه‌هایی محاسبه می‌شود که واقعاً رخ داده‌اند و کاهششان با خط مبنا/پایلوت قابل دفاع باشد.
۲ · زمان عملیاتیجدا از صرفه‌جویی نقدی
ساعت/ماهزمان آزادشده به‌صورت ساعت گزارش می‌شود و خودکار به پول تبدیل نمی‌شود؛ فقط اگر بیمارستان کاهش واقعی overtime/agency یا هزینه نقدی دیگری را مستند کند، آن مبلغ باید جدا وارد شود.
۳ · هزینهٔ اولیه استقرارCAPEX / setup
میلیون تومان۴ · هزینهٔ ماهانهOPEX / service
میلیون تومان/ماهفرمول اصلی
منفعت خالص نقدی ماهانه = هزینه‌های نقدی واقعاً اجتناب‌شده − اشتراک/پشتیبانی − نگهداری − هزینه عملیاتی افزایشی. دوره بازگشت = CAPEX ÷ منفعت خالص مثبت ماهانه.
چیزی که عمداً وارد فرمول نکردیم
ارزش کل دارایی، «ارزش زمان» بدون تبدیل واقعی به هزینه نقدی، ادعای کاهش خطا بدون پایلوت، یا درصد صرفه‌جویی برگرفته از بیمارستان‌های دیگر.
01خط مبنامفقودی، پک اضافه، دوباره‌کاری و زمان جست‌وجو
02حجم و دامنهپک، ابزار، شیفت، ایستگاه و محل‌ها
03زیرساخت موجودPC، شبکه، سرور، برق، backup و امنیت
04RFQ و خدماتتجهیزات، قطعه، آموزش، نصب و پشتیبانی
05پایلوت و اثر واقعیدرصد کاهش‌ها پس از سنجش همان بیمارستان تثبیت می‌شوند
در این مرحله قیمت نهایی، درصد صرفه‌جویی و ROI تأییدشده برای بیمارستان واقعی نداریم. مدل فقط ساختار محاسبه را شفاف می‌کند تا عدد قرارداد از داده و استعلام ساخته شود، نه از حدس.
مبنای این سناریو: حجم رویدادها فرض برنامه‌ریزی برای یک بیمارستان متوسط است؛ درصدهای کاهش فقط پس از پایلوت همان بیمارستان قابل تأییدند. قیمت ایستگاه با ارجاع به بازه عمومی حدود ۱٬۲۵۰ تا ۲٬۲۵۰ دلار برای DPM reader و هزینه‌های جانبی به‌صورت تخمینی وارد شده و به‌علت نوسان بازار ایران نیازمند RFQ روز است. شواهد خارجی فقط امکان ایجاد منفعت را نشان می‌دهند و مستقیماً به ایران تعمیم داده نمی‌شوند. NHS Scan4Safety Evidence · GS1/NHS Surgical Instrument Traceability Guide
۱۲ · شواهد و آمادگی
ما بین «ایده»، «طراحی»، «آزمون» و «مدرک پذیرفته‌شده» تفاوت می‌گذاریم.
در بستهٔ اثبات هسته، F0 تا F3 همچنان دروازه‌های تصمیم هستند و عبور از آن‌ها باید با مدارک واقعی انجام شود.
F0 · تعریف مسئلهOPEN
موجودی، دامنه، معیار، بودجه و طرح آزمون.
F1 · مسیر ممکنOPEN
خواندن اولیه، مسیر مارک و benchmark.
F2 · عملکرد مقاومOPEN
آزمون قفل‌شده، دوام، زمان و شکست‌ها.
F3 · تصمیم ادامهOPEN
پوشش، شواهد، هزینه، تکرارپذیری و پذیرش.
هوش مصنوعی کجای این پروژه است؟
در SITE-08 فقط به‌عنوان لایهٔ اختیاری برای بازیابی اطلاعات، آموزش و تحلیل مطرح است. هویت ابزار، عضویت پک، پذیرش رویداد و مجوز آزادسازی باید از داده و قواعد قابل ممیزی بیایند؛ نبود AI نباید هستهٔ کدینگ را از کار بیندازد.
توسعهٔ اختیاری
چه چیزهایی بعداً می‌توانند روی هسته اضافه شوند؟
هر ماژول دامنه، هزینه، شواهد و پذیرش جدا دارد. کارت‌ها را انتخاب کنید تا مرز هر قابلیت دیده شود.
OPTIONALآموزش تعاملی
نام، تصویر، جایگاه پک و محتوای تأییدشده کنار کار.
FUTUREدستیار متن / صوت
پرسش از سابقه و مدارک؛ با قاعدهٔ عدم حدس.
SEPARATE VALIDATIONکنترل خروج
تگ/گیت و مجوز عبور به‌عنوان لایهٔ مستقل.
SEPARATE SCOPEمدیریت OR / بیمارستان
گسترش آینده به فرایندهای مدیریتی دیگر.
OPTIONAL / PLANNED
آموزش تعاملی ابزار و پک
نمایش نام، تصویر، جایگاه در پک و محتوای آموزشی تأییدشده کنار کاربر.
- رجیستر ابزار و نسخهٔ پک
- IFU/محتوای تأییدشده بیمارستان
- فرایند بازبینی و نسخه‌بندی آموزش
این ماژول چه چیزی را ثابت نمی‌کند؟
جایگزین صلاحیت حرفه‌ای، IFU یا آموزش رسمی کارکنان نیست.
نمایش مفهومی کنترل خروج پک
ماژول مستقل از DPM تک‌ابزاریک حالت را انتخاب کنید
کنترل خروج می‌تواند بر اساس هویت پک/تگ مناسب نقطهٔ خروج و مجوز ثبت‌شده کار کند. فناوری، محل نصب و نرخ خطا باید جدا آزموده شوند.
این دمو ادعای جلوگیری قطعی از سرقت یا مکان‌یابی زنده نمی‌کند. DataMatrix فقط وقتی دیده می‌شود که خوانده شود؛ گیت خروج ممکن است به فناوری دیگری نیاز داشته باشد.
هستهکدینگ و کنترل پک
محور اصلی پروژه و شرط همهٔ توسعه‌ها.
اختیاری ۱آموزش
بعد از ورود محتوای تأییدشده.
اختیاری ۲دستیار
فقط روی منابع قابل استناد و audit.
اختیاری ۳کنترل خروج / توسعه مدیریتی
دامنه و validation جداگانه.
۱۳ · درباره ما
این صفحه یک پروپوزال نمایشی است؛ هدف آن کدینگ و رهگیری ابزارهای جراحی است.
در این بخش، معرفی کوتاه من و شرح کلی پروژه آمده است. برای تماس، بخش «ارتباط با ما» را ببینید.
دربارهٔ من
سید امین صالح‌خو — طراح و توسعه‌دهنده، ساکن همدان، ایران.
تمرکز اصلی: طراحی محصول، نمونه‌سازی، ارائه‌های تعاملی و پیاده‌سازی فنی پروپوزال‌های فنی-پزشکی.
نمونه‌کار: CGTrader — rhyton · YouTube — @studiorhyton5527
دربارهٔ پروژه — SITE-10B
پروپوزال سامانهٔ کدینگ یکتا و رهگیری ابزارهای جراحی: از آماده‌سازی و بسته‌بندی تا استریلیزاسیون، استفاده و آزادسازی.
تفکیک سه مفهوم Instrument / Pack / Tag به مدل عمومی اضافه شده است؛ داده‌های تجربهٔ جهانی به‌عنوان شواهد خارجی و با محدودیت منبع نمایش داده شده‌اند.
این نسخه یک Demo / Proposal است و برای استفادهٔ بالینی نیست؛ نتیجهٔ واقعی سامانه نیازمند آزمون و پذیرش جداگانه است.
۱۴ · ارتباط با ما
برای سؤالات دربارهٔ پروژه، درخواست استعلام یا هماهنگی بازدید بیمارستان، تماس بگیرید.
روی هر یک از مسیرهای زیر کلیک کنید؛ ایمیل، صفحهٔ ارسال ایمیل را باز می‌کند و تلفن، شماره‌گیری را شروع می‌کند.
تلفن / واتساپ
ساعات پاسخ‌گویی: شنبه تا چهارشنبه، ۹ تا ۱۷ (به وقت محلی).
+98 918 909 3319شروع شمارهگیریمحل
همدان، ایران.
همکاری‌های حضوری یا آنلاین امکان‌پذیر است.۱۵ · آغاز همکاری
بازگشت به ابتداشروع از شناخت بیمارستان؛ نه از فروش یک نسخهٔ ثابت.
گام اول، بازدید و شناخت ساختار پک، مسیر CSSD، اتاق عمل، تجهیزات، زیرساخت و شاخص‌های فعلی است. سپس دامنهٔ فنی، هزینه، معیار پذیرش و برنامهٔ پایلوت همان بیمارستان تعریف می‌شود.
۱. شناخت وضع موجود۲. تعیین دامنه۳. استعلام و طراحی۴. اثبات هسته۵. پایلوت و پذیرش