سامانه اطلاعات بیمارستانی (HIS)
سامانهٔ اطلاعات بیمارستانی یکی از سختترین دستههای نرمافزار سازمانی است و دلیلش پیچیدگی فنی نیست.
دلیلش این است که نمیشود خاموشش کرد. فروشگاهی که دو ساعت پایین باشد، فروش از دست میدهد. بیمارستانی که دو ساعت سامانه نداشته باشد، اورژانسش کاغذی میشود و کسی ممکن است آسیب ببیند.
هر تصمیمی در این حوزه از همینجا شروع میشود.
HIS از چه بخشهایی ساخته میشود
پذیرش و هویت بیمار. پایهایترین بخش و پرخطاترین. اگر یک بیمار دو پرونده داشته باشد، سوابقش تکهتکه است و این خطای بالینی میسازد.
پروندهٔ الکترونیک سلامت. شرح حال، دستورات پزشک، سیر بیماری، نتایج.
بستری و مدیریت تخت. پذیرش، انتقال، ترخیص، اشغال تخت.
اتاق عمل. برنامهریزی، تیم جراحی، مصرفشدنیها.
دارو و انبار. تجویز، توزیع، موجودی، تاریخ انقضا.
آزمایشگاه و تصویربرداری. درخواست، نمونه، نتیجه، بایگانی تصویر.
مالی و بیمه. صورتحساب، سهم بیمه، سهم بیمار، اسناد.
گزارشهای نظارتی.
هر کدام از اینها در بازار جهانی محصول مستقلی دارد. اینکه یک تیم بتواند همه را با کیفیت بسازد، فرض واقعبینانهای نیست.
سختترین بخش: هویت بیمار
اگر یک چیز را باید از اول درست کرد، همین است.
بیمار با کد ملی میآید، یا با گذرنامه، یا بیهوش و بیمدرک. همان بیمار سه سال بعد با نام کمی متفاوت برمیگردد. نوزادی که هنوز کد ملی ندارد. اتباع.
پروندهٔ تکراری، شایعترین و پرعارضهترین مشکل داده در بیمارستان است. پزشکی که سابقهٔ حساسیت دارویی بیمار را نمیبیند چون در پروندهٔ دیگری ثبت شده، ممکن است تصمیم خطرناکی بگیرد.
آنچه لازم است: تطبیق احتمالی هنگام پذیرش که موارد مشکوک را نشان دهد، ابزار ادغام پروندهها با ثبت کامل تاریخچه، و پذیرش این واقعیت که همیشه بخشی از کار دستی میماند. سامانهای که ادعا کند این را کامل خودکار حل میکند، ادعایش را بررسی کنید.
بسازیم یا بخریم؟
جواب صریح ما: هستهٔ HIS را نسازید.
پذیرش، پرونده، بستری، دارو و مالی — اینها دههها بلوغ محصولی دارند، الزامات نظارتی سنگین، و هزاران حالت مرزی که تیم شما در دو سال کشف نمیکند. ساختنشان از صفر تقریباً همیشه تصمیم غلطی است.
آنچه ساختن یا سفارشیسازیاش منطقی است:
اتصالها و یکپارچهسازی. هر بیمارستان ترکیب متفاوتی از سامانهها دارد و همین لایه، بیشترین کار سفارشی واقعی را میسازد.
پرتال بیمار. نوبتدهی، دیدن نتایج، پرداخت. معمولاً ضعیفترین بخش محصولات آماده است.
داشبورد مدیریتی. گزارشهای واقعی مدیریت بیمارستان، که تقریباً همیشه با گزارشهای استاندارد محصول جور درنمیآید.
فرایندهای خاص همان مرکز. کلینیک تخصصی، پروتکل درمانی خاص، پژوهش بالینی.
اپلیکیشنهای جانبی: ویزیت آنلاین، پیگیری پس از ترخیص، مدیریت نوبت. اینها با HIS حرف میزنند و بخشی از آن نیستند. الگویش را در ویزیت آنلاین نوشتهایم.
یکپارچهسازی، جایی که پروژه واقعاً انجام میشود
بیمارستان معمولاً چند سامانه دارد که باید با هم کار کنند: HIS، آزمایشگاه، تصویربرداری، داروخانه، حسابداری، بیمه، سامانههای وزارت.
دو استاندارد در این حوزه هستند و بدانید کدام کجاست:
HL7 نسخهٔ ۲ هنوز رایجترین است، بهویژه در سامانههای قدیمیتر. قدیمی و سختخوان و همهجا هست.
FHIR مدرنتر و مبتنی بر رابطهای وب است و مسیر آینده. برای هر بخش جدیدی که میسازید، مبنا را روی این بگذارید.
و در ایران، لایهٔ سومی هم هست: اتصال به سامانههای وزارت بهداشت و بیمهها، که قالبهای خاص خودشان را دارند و از هر دو استاندارد بالا مستقلاند. این اتصالها فرایند اداری دارند و باید بهعنوان قلم زمانی مستقل و موازی برنامهریزی شوند، نه بخشی از کار توسعه.
توصیهٔ معماری: همهٔ اتصالها از یک لایهٔ واسط عبور کنند، نه اینکه هر سامانه مستقیم به بقیه وصل شود. با شش سامانه، حالت مستقیم یعنی پانزده اتصال دوطرفه. الگوهایش در یکپارچهسازی سامانهها آمده.
در دسترس بودن، که اینجا معنای دیگری دارد
سامانهای که نمیشود خاموشش کرد، چند الزام دارد که در نرمافزار سازمانی معمولی اختیاریاند:
حالت کاغذی. بیمارستان باید بداند اگر سامانه پایین آمد چه میکند و بعد داده را چطور وارد میکند. این تمرین باید انجام شود، نه فقط نوشته.
نسخهٔ فقطخواندنی. حتی اگر ثبت ممکن نباشد، دیدن سوابق باید ممکن بماند. این تفکیک، بیشترین ارزش را در بحران دارد و کمترین هزینه را.
بازهٔ انتشار نسخه. بیمارستان ساعت خلوت ندارد. انتشار باید بدون قطعی انجام شود، با همان الگوهای موازی که در مدیریت انتشار گفتیم.
پشتیبان و بازیابی آزموده. نه فقط پشتیبانگیری — آزمودن بازیابی.
آنچه پروژههای HIS را شکست میدهد
از تجربهٔ این حوزه، سه علت غالب:
نادیدهگرفتن جریان کار واقعی. پرستاری که در شیفت شلوغ باید هفت کلیک بکند تا یک دارو ثبت کند، یادداشت کاغذی مینویسد و آخر شیفت وارد میکند — و از آن لحظه، دادههای زمانی سامانه غلطاند. ساعتها کنار تخت بگذرانید پیش از طراحی هر صفحهای.
آموزش ناکافی. کارکنان بالینی وقت آموزش طولانی ندارند. رابط باید برای استفادهٔ زیر فشار طراحی شود، نه برای کاربری که آموزش دیده و آرام است.
مهاجرت داده که دستکم گرفته شده. سوابق سالها، با کیفیت متغیر و کدگذاریهای مختلف. این را در مهاجرت داده گفتیم و در بیمارستان حساستر است، چون دادهٔ ازدسترفته ممکن است دادهٔ بالینی باشد.
اگر پروژهای در این حوزه دارید
سه سؤال که پیش از هر تصمیمی جواب بخواهند:
چه چیزی را واقعاً باید بسازیم و چه چیزی از قبل هست؟ جواب صادقانه معمولاً یعنی هستهٔ HIS آماده، و کار سفارشی روی اتصالها و لایههای بیرونی.
کدام سامانه مرجع هر داده است؟ بدون این تصمیم، دو سامانه دو عدد متفاوت میدهند و کسی نمیداند کدام درست است.
اگر این سامانه دو ساعت پایین بیاید چه میشود؟ اگر جواب قابل قبول نیست، معماری باید از روز اول با این فرض بسته شود، نه اینکه بعداً «مقاومسازی» شود.