سی فیلد، یک پورتال بیمه، صفر API

Salam Health یک سیستم اطلاعات بیمارستانی برای دیالیز است — پرستاران، فرم‌های درمانی، انبارداری، حسابداری، پانزده مرکز در سراسر استان. بیشتر آن را به درستی ساختیم: API، PostgreSQL، همگام‌سازی آفلاین در جایی که اتصال ضعیف بود.

ادعاهای بیمه ضربه اخلاقی هفتگی بود. پرونده بالینی دقیق بود. پورتال وب بیمه‌گر ملی همان اطلاعات را دوباره می‌خواست — بیش از سی فیلد به ازای هر ادعا — دستی وارد شود. یک ادعا می‌توانست بیشتر یک روز را بگیرد. آن را در مراکز ضرب کنید و دارید به پرستاران پول می‌دهید تا منشی ورود داده باشند.

بیمه‌گر پورتال داشت، نه API

درباره ادغام پرسیدیم. EDI مناسب یا API پایدار فصل‌هایی را می‌طلبید که نداشتیم، اگر اصلاً اتفاق می‌افتاد. پورتال کار می‌کرد. انسان‌ها می‌توانستند از طریق آن ادعا ارسال کنند. فقط کند، تکراری بود، و دقیقاً نوع کاری بود که وقتی افراد هوشمند باید تحت فشار ضرب‌الاجل انجامش دهند فاسد می‌شود.

پس از Puppeteer استفاده کردیم. نه به این دلیل که ظریف است. به این دلیل که بک‌اند ما از قبل payload ادعا را داشت و پورتال تنها درب بود.

چه ساختیم

موجودیت‌های HIS را یک بار به فیلدهای فرم نگاشتیم، با اعتبارسنجی قبل از رسیدن هر چیزی به صف. جلسات headless ادعاها را دسته‌ای پر کردند و ارسال کردند. هر اجرا موفقیت یا شکست هر ادعا را ثبت می‌کرد تا کارکنان بتوانند استثناها را دستی بررسی کنند به جای حدس زدن اینکه ربات شبه‌ما چه کرده.

ادعای ناهنجار را عمدتاً به انسان‌ها دادیم. هدف حذف نود درصدی بود که تکرار محض بود.

پردازش مسیر استاندارد از حدود یک هفته به حدود یک روز کاهش یافت. این عددی است که مردم به یاد می‌آورند. تغییر عملیاتی ساده‌تر بود: پرستاران به کار بیمار برگشتند.

زندگی با Puppeteer در تولید

پورتال‌ها تغییر می‌کنند. انتخابگرها خراب می‌شوند. اسکریپت‌ها را مثل کد تولیدی رفتار کردیم — نسخه‌بندی شده، نظارت شده، تحت مالکیت مهندسی، نه یک بار در لپ‌تاپ کسی. این بدهی فنی است که آگاهانه انتخاب می‌کنید وقتی جایگزین کار دستی در پانزده مرکز است.

با همان محدودیت‌ها همان تصمیم را می‌گرفتم. داده‌های داخلی تمیز و رابط کاربری خارجی خصمانه جای بدی برای اضافه کردن نیروی انسانی است.