چگونه اجرای مواد ۴۲، ۵۰، ۵۳، ۵۴ و ۵۶ قانون حمایت از خانواده و جوانی جمعیت می‌تواند به پروتوتایپ پایگاه ملی سلامت و بازارگاه سلامت دیجیتال کشور تبدیل شود؟

سامانه باروری سالم؛ پروتوتایپ پایگاه ملی سلامت و الگوی تحقق بازارگاه سلامت دیجیتال در چارچوب قوانین جمعیتی و برنامه هفتم توسعه

۱. مقدمه: از اجرای یک تکلیف قانونی تا خلق یک ظرفیت ملی

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

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

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

در مقابل، رویکرد زیست‌بوم‌محور، به‌جای تمرکز بر ساخت یک نرم‌افزار بزرگ، بر تعریف لایه‌های استاندارد، قراردادهای تبادل، خدمات مشترک، مدل‌های داده قابل استفاده مجدد و زیرساخت‌های پایدار برای تحلیل اطلاعات تأکید دارد.

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

فرضیه محوری مقاله این است که اگر سامانه باروری سالم از ابتدا بر مبنای یک معماری چندلایه، استانداردمحور و تحلیلی طراحی شود، می‌تواند علاوه بر انجام وظایف قانونی خود، به نخستین نمونه عملی برای آزمودن بخش مهمی از معماری پایگاه ملی سلامت و الگوی تعامل‌پذیری بازارگاه سلامت دیجیتال ایران تبدیل شود.

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

۲. پنج ماده قانونی؛ پنج پنجره به یک مسئله مشترک

مواد ۴۲، ۵۰، ۵۳، ۵۴ و ۵۶ قانون حمایت از خانواده و جوانی جمعیت را می‌توان از دو منظر مطالعه کرد: نخست، تکالیف تخصصی هر ماده و دوم، ظرفیت مشترک آنها برای شکل‌دهی به یک زنجیره ملی اطلاعات سلامت.

۲ـ۱. ماده ۴۲: ثبت و پایش درمان ناباروری

درمان ناباروری از جمله حوزه‌هایی است که فرایند ارائه خدمت آن می‌تواند در مراکز مختلف، در زمان‌های متفاوت و با مشارکت ارائه‌دهندگان متعدد انجام شود. پرونده درمان ممکن است شامل اطلاعات زوجین، سوابق تشخیصی، اقدامات درمانی، نتایج آزمایش‌ها، برنامه درمان، چرخه‌های درمان ناباروری و پیامدهای آن باشد.

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

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

نکته معماری مهم آن است که رجیستری ناباروری نباید به مخزنی جزیره‌ای تبدیل شود که اطلاعات آن فقط از طریق بارگذاری فایل یا گزارش‌های دوره‌ای در دسترس قرار گیرد. این رجیستری باید در قالب یک مؤلفه تخصصی، با مدل داده روشن و قراردادهای تبادل استاندارد، در زیست‌بوم ملی سلامت جای گیرد.

۲ـ۲. ماده ۵۰: مراقبت یکپارچه مادر باردار

مراقبت یکپارچه مادر باردار، از نظر معماری اطلاعات، یکی از مهم‌ترین محورهای این پیشنهاد است. مراقبت از مادر در طول بارداری، به‌طور طبیعی فرایندی طولی است که از مجموعه‌ای از ملاقات‌ها، ارزیابی‌های بالینی، آزمایش‌ها، مداخلات، ارجاع‌ها و تصمیم‌های مراقبتی تشکیل می‌شود.

یکپارچگی این فرایند به معنای آن نیست که تمام اطلاعات باید در یک نرم‌افزار واحد تولید و ذخیره شوند؛ بلکه به این معناست که اطلاعات مرتبط با مادر، با رعایت ضوابط دسترسی، در زمان و مکان مورد نیاز برای ارائه مراقبت قابل دسترسی و تفسیر باشند.

الزام دسترسی برخط به پرونده الکترونیک سلامت مادر باردار در بازارگاه سلامت الکترونیک، اهمیت این موضوع را دوچندان می‌کند. اگر قرار باشد ارائه‌دهندگان مجاز در بخش دولتی و خصوصی بتوانند به اطلاعات لازم برای مراقبت دسترسی داشته باشند، وجود استانداردهای مشترک شناسایی بیمار، ساختار داده، تبادل اطلاعات، کنترل دسترسی و ثبت رویدادها ضروری است.

از سوی دیگر، مراقبت یکپارچه باید از الگوها، پروتکل‌ها و شیوه‌نامه‌های مدون پیروی کند. بنابراین، داده‌های ثبت‌شده باید تا حد امکان امکان سنجش انطباق با برنامه‌های مراقبتی، شناسایی تأخیرها، پایش پیوستگی خدمات و بررسی پیامدهای مراقبت را فراهم کنند.

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

در اینجا باید بر یک تمایز تأکید کرد: ثبت داده، اندازه‌گیری شاخص و اعمال اثر مالی بر پرداخت، سه فرایند متمایزند. معماری اطلاعات می‌تواند شواهد معتبر و قابل حسابرسی را فراهم کند، اما قواعد محاسبه و اعمال آثار مالی باید به‌صورت شفاف، قابل توضیح و مطابق مقررات مربوط تعریف شوند.

۲ـ۳. ماده ۵۳: غربالگری جنینی و ثبت اطلاعات مرتبط

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

در این حوزه، ثبت صرف یک نتیجه آزمایش یا یک کد تشخیصی کافی نیست. برای تحلیل معتبر، باید زمینه بالینی، زمان انجام آزمون، نوع روش، نتیجه، تفسیر تخصصی و اقدام بعدی نیز، متناسب با نیاز و ضوابط قانونی، قابل شناسایی باشند.

همچنین، غربالگری با تشخیص قطعی یکسان نیست. معماری داده باید این تفاوت را حفظ کند و از تبدیل نتیجه غربالگری به یک برچسب قطعی و گمراه‌کننده جلوگیری کند.

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

۲ـ۴. ماده ۵۴: سامانه باروری سالم به‌عنوان نقطه اتصال

ماده ۵۴ در این چارچوب نقش محوری دارد؛ زیرا سامانه موضوع این ماده می‌تواند نقطه اتصال اطلاعات و فرایندهای مرتبط با سایر مواد قانونی باشد.

اگر سامانه باروری سالم صرفاً به یک نرم‌افزار مستقل برای دریافت داده‌های پراکنده تبدیل شود، بخش مهمی از ظرفیت آن از دست خواهد رفت. در مقابل، اگر از ابتدا به‌عنوان یک مؤلفه ملی مبتنی بر استانداردهای مشترک و معماری چندلایه طراحی شود، می‌تواند بستری برای تجمیع منطقی داده‌ها، پایش شاخص‌ها، تبادل اطلاعات و ارائه خدمات تحلیلی فراهم کند.

مقصود از تجمیع منطقی، الزاماً انتقال تمام داده‌های عملیاتی به یک پایگاه واحد نیست. ممکن است بخشی از داده‌ها در سامانه‌های مبدأ باقی بمانند، بخشی از طریق رابط‌های استاندارد قابل بازیابی باشند و مجموعه‌ای از داده‌های منتخب و مورد نیاز برای تحلیل در لایه پایدار تحلیلی نگهداری شوند.

این تمایز، از نظر هزینه، امنیت، توسعه‌پذیری و حفظ استقلال سامانه‌های تخصصی اهمیت اساسی دارد.

۲ـ۵. ماده ۵۶: فرایندهای قانونی مرتبط با سقط جنین

فرایندهای قانونی مرتبط با سقط جنین، به دلیل حساسیت پزشکی، حقوقی و اجتماعی، نیازمند ثبت دقیق مراحل و تصمیم‌های مجاز هستند. در طراحی اطلاعاتی این حوزه، باید میان درخواست، مستندات پزشکی، ارزیابی تخصصی، تصمیم مرجع صلاحیت‌دار، مجوز قانونی و ثبت نتیجه نهایی تمایز قائل شد.

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

همچنین، دسترسی به اطلاعات هویتی و جزئیات پرونده باید به‌شدت کنترل‌شده و مبتنی بر نقش، هدف استفاده و مجوز قانونی باشد. داده‌های حساس این حوزه نیز برای تحلیل‌های مدیریتی باید تا حد امکان به‌صورت تجمیعی، مستعارسازی‌شده یا ناشناس‌سازی‌شده و مطابق ضوابط حفاظت از داده به کار گرفته شوند.

این ماده نشان می‌دهد که معماری یکپارچه سلامت صرفاً مسئله تبادل داده نیست؛ بلکه مسئله تنظیم دقیق مرزهای دسترسی، مسئولیت‌پذیری و حفاظت از حقوق افراد نیز هست.

۲ـ۶. جمع‌بندی الزامات مشترک

پنج ماده یادشده از نظر موضوعی یکسان نیستند، اما در سطح معماری اطلاعات، مجموعه‌ای از نیازهای مشترک دارند:

• شناسایی معتبر افراد و پیوند منطقی پرونده‌ها؛

• ثبت استاندارد داده‌های بالینی و فرایندی؛

• حفظ پیوستگی اطلاعات در طول زمان؛

• تبادل برخط اطلاعات میان سامانه‌های مجاز؛

• ثبت منشأ داده و قابلیت پیگیری تغییرات؛

• کنترل دسترسی متناسب با نقش و هدف؛

• استخراج شاخص‌های عملکردی و مدیریتی؛

• ایجاد امکان پایش ملی و تصمیم‌گیری مبتنی بر شواهد.

بنابراین، مسئله اصلی آن نیست که برای هر ماده یک نرم‌افزار مجزا ایجاد شود؛ مسئله این است که چگونه می‌توان این تکالیف را در قالب مجموعه‌ای از خدمات تخصصی، بر بستر یک معماری ملی مشترک، محقق کرد.

۳. مسئله معماری: چرا نباید به توسعه یک سامانه مونولیتیک بسنده کرد؟

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

چنین معماری‌ای لزوماً در همه شرایط نامناسب نیست و برای بعضی کاربردهای محدود می‌تواند انتخابی ساده و اقتصادی باشد. با این حال، در پروژه‌ای ملی که چندین حوزه تخصصی، مراکز ارائه خدمت، سامانه‌های مبدأ و نیازهای مدیریتی را به هم مرتبط می‌کند، وابستگی شدید اجزا به یکدیگر می‌تواند محدودیت‌هایی جدی ایجاد کند.

در یک سامانه مونولیتیک گسترده، تغییر در مدل داده یک حوزه ممکن است به تغییرات زنجیره‌ای در بخش‌های دیگر منجر شود. افزودن یک خدمت جدید می‌تواند به توسعه مجدد قسمت‌هایی از سامانه نیاز داشته باشد. همچنین، اتصال به سامانه‌های مستقل موجود، گاهی از طریق رابط‌های اختصاصی و شکننده انجام می‌شود.

مهم‌تر از همه، هنگامی که گزارش‌گیری‌های سنگین و تحلیل‌های چندبعدی مستقیماً روی پایگاه عملیاتی انجام شوند، ممکن است عملکرد فرایندهای ثبت و ارائه خدمت تحت تأثیر قرار گیرد.

در پروژه‌ای مانند باروری سالم، این محدودیت‌ها می‌توانند در مراحل بعدی و با افزایش تعداد مراکز، حجم داده‌ها و پیچیدگی شاخص‌ها آشکار شوند؛ زمانی که اصلاح معماری هزینه بیشتری خواهد داشت.

راه‌حل پیشنهادی، کنار گذاشتن سامانه‌های عملیاتی نیست؛ بلکه تفکیک روشن مسئولیت‌ها میان لایه‌های عملیاتی، تبادل، نگهداری پایدار داده و تحلیل است.

در این الگو، سامانه‌های عملیاتی مسئول ثبت و اجرای فرایندهای روزمره هستند، لایه هم‌کنش‌پذیری تبادل استاندارد را امکان‌پذیر می‌کند، لایه تحلیلی داده‌های مورد نیاز برای تحلیل را سازمان‌دهی می‌کند و داشبوردها و ابزارهای تصمیم‌یار از داده‌های آماده تحلیل بهره می‌برند.

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

۴. چرا OLAP؛ و چرا نه OLAP به‌جای OLTP؟

برای تبیین پیشنهاد، باید میان دو مفهوم OLTP و OLAP تمایز قائل شد.

پردازش تراکنشی برخط (OLTP) برای انجام عملیات روزمره طراحی می‌شود: ثبت اطلاعات بیمار، ایجاد پرونده، ثبت نتیجه آزمایش، تکمیل ملاقات، ثبت درخواست خدمت، به‌روزرسانی وضعیت فرایند و مدیریت تراکنش‌های عملیاتی.

در مقابل، پردازش تحلیلی برخط (OLAP) برای تحلیل حجم زیادی از داده‌ها، مقایسه ابعاد مختلف، بررسی روندها، محاسبه شاخص‌ها و پاسخ‌گویی به پرسش‌های مدیریتی طراحی می‌شود.

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

در نتیجه، پیشنهاد این مقاله جایگزینی OLTP با OLAP نیست؛ بلکه ایجاد معماری‌ای است که در آن، فرایندهای عملیاتی و تحلیلی از یکدیگر تفکیک شده و در عین حال، با قراردادهای داده‌ای روشن به هم متصل باشند.

در این الگو، سامانه‌های عملیاتی می‌توانند مستقل از فناوری داخلی خود فعالیت کنند؛ داده‌های منتخب از طریق رابط‌های استاندارد یا سازوکارهای کنترل‌شده انتقال داده به لایه تحلیلی منتقل شوند؛ و داشبوردها بدون ایجاد بار نامتناسب بر سامانه‌های ارائه خدمت، اطلاعات مورد نیاز را دریافت کنند.

از منظر راهبردی، این تصمیم یک پیامد مهم دارد: سامانه باروری سالم از ابتدا نه صرفاً به‌عنوان یک نرم‌افزار ثبت اطلاعات، بلکه به‌عنوان یک محصول داده‌محور با قابلیت پشتیبانی از عملیات، تبادل و تحلیل طراحی می‌شود.

۵. معماری پیشنهادی سامانه باروری سالم

معماری پیشنهادی از چند لایه متمایز اما مرتبط تشکیل می‌شود. این لایه‌ها نباید به‌عنوان محصولات کاملاً مستقل و فاقد ارتباط دیده شوند؛ بلکه هر یک مسئولیت مشخصی در زنجیره تولید، تبادل، نگهداری و بهره‌برداری از داده بر عهده دارند.

۵ـ۱. لایه پرونده الکترونیک سلامت در محیط ارائه خدمت

این لایه محل اصلی ثبت داده‌های بالینی و اجرای فرایندهای روزمره است. مراکز درمان ناباروری، مراکز مراقبت بارداری، آزمایشگاه‌ها، مراکز تصویربرداری و سایر ارائه‌دهندگان مجاز می‌توانند از سامانه‌های عملیاتی خود استفاده کنند، مشروط بر اینکه الزامات تبادل و ثبت داده‌های مورد نیاز را رعایت کنند.

اصل اساسی در اینجا آن است که همه ارائه‌دهندگان الزاماً مجبور به استفاده از یک نرم‌افزار واحد نباشند. آنچه باید یکسان شود، قراردادهای داده، حداقل الزامات اطلاعاتی، قواعد شناسایی، ساختار تبادل و الزامات امنیتی است.

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

۵ـ۲. لایه هم‌کنش‌پذیری و تبادل استاندارد

این لایه مسئول برقراری ارتباط میان سامانه‌های مبدأ، خدمات ملی و سایر اجزای زیست‌بوم سلامت است.

در اینجا استفاده از استاندارد HL7 FHIR، به‌ویژه برای تعریف منابع اطلاعاتی، پروفایل‌های ملی، قراردادهای API، قواعد اعتبارسنجی و تبادل ساختاریافته داده، می‌تواند نقش محوری داشته باشد.

برای نمونه، بسته به نیازهای مصوب، منابع FHIR مرتبط با Patient، RelatedPerson، Practitioner، Organization، Encounter، Observation، DiagnosticReport، ServiceRequest، Procedure، CarePlan، Consent و Provenance می‌توانند در طراحی مدل اطلاعاتی مورد استفاده قرار گیرند.

البته صرف استفاده از FHIR به معنای تحقق هم‌کنش‌پذیری نیست. هم‌کنش‌پذیری واقعی به تعریف پروفایل‌های ملی، شناسه‌های معتبر، واژگان و کدگذاری‌های استاندارد، قواعد اعتبارسنجی و معنای مشترک داده‌ها نیاز دارد.

در این معماری، هر API باید قرارداد مشخصی داشته باشد: چه داده‌ای را دریافت می‌کند، چه داده‌ای را بازمی‌گرداند، چه کسی مجاز به استفاده از آن است، چه خطاهایی ممکن است رخ دهد و چگونه نسخه‌های مختلف آن مدیریت می‌شوند.

در صورت استفاده از یک درگاه تبادل ملی، این درگاه می‌تواند وظایفی مانند احراز هویت سامانه‌ها، اعمال سیاست‌های دسترسی، کنترل ترافیک، ثبت رویدادها و مدیریت APIها را بر عهده گیرد. با این حال، درگاه تبادل جایگزین استانداردسازی معنایی داده‌ها نیست؛ بلکه بخشی از زیرساخت اجرایی هم‌کنش‌پذیری است.

۵ـ۳. لایه رسوب پایدار و تحلیلی داده

داده‌های عملیاتی و تبادل‌شده، پس از طی فرایندهای اعتبارسنجی، کنترل کیفیت، تطبیق شناسه‌ها و تعیین منشأ، می‌توانند در یک لایه پایدار داده سازمان‌دهی شوند.

هدف این لایه، ایجاد مجموعه‌ای قابل اتکا برای تحلیل طولی و چندمنبعی است؛ مجموعه‌ای که تغییرات سامانه‌های عملیاتی، به‌تنهایی ساختار و قابلیت استفاده از داده‌های تاریخی را از بین نبرد.

در این بخش می‌توان از الگوهای انباره داده، مخزن داده تحلیلی یا معماری‌های ترکیبی استفاده کرد. انتخاب فناوری باید بر اساس حجم داده، تنوع منابع، الزامات امنیتی، هزینه نگهداری و نیازهای تحلیلی انجام شود؛ نه صرفاً بر اساس محبوبیت یک محصول یا فناوری خاص.

برای پشتیبانی از تحلیل‌های سلامت، مدل‌هایی نظیر OMOP Common Data Model نیز می‌توانند در جایگاه مناسب بررسی شوند. در این صورت، داده‌های استانداردشده عملیاتی و تبادلی می‌توانند در یک مدل تحلیلی سازگار سازمان‌دهی شوند، بی‌آنکه مدل تحلیلی جایگزین مدل عملیاتی یا قراردادهای FHIR شود.

در اینجا تمایز مهمی وجود دارد: FHIR عمدتاً برای تبادل و دسترسی ساختاریافته به اطلاعات سلامت کاربرد دارد، در حالی که OMOP می‌تواند برای سازمان‌دهی داده‌های مشاهده‌ای و تحلیل‌های پژوهشی و جمعیتی مناسب باشد. این دو استاندارد رقیب یکدیگر نیستند و در صورت طراحی صحیح، می‌توانند نقش‌های مکمل داشته باشند.

۵ـ۴. لایه بازنمایی، داشبورد و هوشمندی

این لایه، داده‌های پایدار را به شاخص‌ها، نماهای مدیریتی و ابزارهای تصمیم‌یار تبدیل می‌کند.

داشبوردهای سامانه باروری سالم می‌توانند بر اساس نیازهای تعریف‌شده، گروه‌های مختلفی از شاخص‌ها را پوشش دهند:

• شاخص‌های پوشش و دسترسی به خدمات؛

• شاخص‌های پیوستگی و زمان‌بندی مراقبت؛

• شاخص‌های مربوط به فرایندهای درمان ناباروری؛

• شاخص‌های فرایندی مرتبط با غربالگری جنینی؛

• شاخص‌های ثبت، پیگیری و تکمیل اطلاعات؛

• شاخص‌های تجربه و رضایت دریافت‌کنندگان خدمت؛

• شاخص‌های کیفیت داده و انطباق با استانداردها؛

• شاخص‌های مدیریتی مورد نیاز برای پایش اجرای تکالیف قانونی.

هر شاخص باید تعریف رسمی داشته باشد؛ از جمله صورت، مخرج، جامعه هدف، منبع داده، دوره محاسبه، قواعد حذف و شمول، مسئول تأیید و تاریخ اعتبار تعریف.

همچنین باید میان داشبوردهای عملیاتی، مدیریتی و سیاستی تمایز گذاشت. داشبورد عملیاتی به وضعیت جاری فرایندها می‌پردازد؛ داشبورد مدیریتی عملکرد مراکز و برنامه‌ها را بررسی می‌کند؛ و داشبورد سیاستی برای مشاهده روندهای کلان و پشتیبانی از تصمیم‌گیری در سطح ملی طراحی می‌شود.

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

۵ـ۵. لایه افقی حکمرانی، امنیت و حفاظت از داده

حکمرانی داده نباید به یک بخش انتهایی یا ماژول جانبی محدود شود. این لایه باید در تمام اجزای معماری حضور داشته باشد و شامل تعیین مالکیت و مسئولیت داده، قواعد دسترسی، مدیریت رضایت در موارد مقتضی، ثبت منشأ، کنترل تغییرات، ممیزی، کیفیت داده و نگهداری امن اطلاعات باشد.

در حوزه باروری سالم، حساسیت اطلاعات اقتضا می‌کند که دسترسی بر اساس اصل حداقل اختیار و نیاز واقعی به اطلاعات طراحی شود. همچنین، دسترسی به داده‌های شناسایی‌پذیر برای ارائه مراقبت باید از دسترسی به داده‌های مورد استفاده در تحلیل‌های جمعیتی و مدیریتی متمایز باشد.

بنابراین، باید سازوکارهای جداگانه‌ای برای دسترسی درمانی، دسترسی مدیریتی، استفاده پژوهشی و انتشار آمار تجمیعی تعریف شود. هر یک از این موارد تابع هدف، مجوز و سطح دسترسی متفاوتی است.

۶. سامانه باروری سالم به‌مثابه آزمایشگاه واقعی پایگاه ملی سلامت

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

از این منظر، سامانه باروری سالم می‌تواند به‌عنوان یک حوزه کاربردی واقعی برای آزمودن این قابلیت‌ها به کار گرفته شود.

نخست، این سامانه به شناسه‌گذاری معتبر افراد و ارتباط دادن اطلاعات آنان در طول زمان نیاز دارد. دوم، داده‌های آن از منابع مختلف و با قالب‌های متفاوت تولید می‌شوند. سوم، ارائه خدمت مستلزم تبادل اطلاعات در زمان مناسب است. چهارم، پایش ملی نیازمند حفظ داده‌های تاریخی و محاسبه شاخص‌های چندبعدی است. پنجم، حساسیت اطلاعات، طراحی سازوکارهای امنیتی و کنترل دسترسی را به یک ضرورت اساسی تبدیل می‌کند.

این مجموعه نیازها، بسیاری از مسائل بنیادی پایگاه ملی سلامت را در مقیاسی مشخص و قابل مدیریت بازتولید می‌کند.

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

این الگو می‌تواند بعداً برای حوزه‌هایی مانند دیابت، بیماری‌های قلبی‌عروقی، سرطان، سلامت روان، سلامت کودک و سایر برنامه‌های ملی توسعه یابد.

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

در نتیجه، دستاورد اصلی پروژه می‌تواند فراتر از یک سامانه موضوعی باشد: ایجاد یک الگوی مرجع که توسعه خدمات جدید را سریع‌تر، کم‌هزینه‌تر و سازگارتر با معماری ملی سلامت کند.

۷. ارتباط با بازارگاه سلامت دیجیتال: از پذیرش نرم‌افزار تا تضمین قابلیت تعامل

بازارگاه سلامت دیجیتال، در معنای راهبردی خود، نباید صرفاً محلی برای معرفی محصولات نرم‌افزاری یا فهرست کردن تأمین‌کنندگان باشد. این بازارگاه زمانی می‌تواند نقش ملی ایفا کند که چارچوبی برای پذیرش، ارزیابی، اتصال و بهره‌برداری از سامانه‌های سلامت فراهم آورد.

سامانه باروری سالم می‌تواند این ظرفیت را در یک حوزه تخصصی به‌صورت عملیاتی بیازماید.

در این الگو، هر محصول یا سامانه ارائه‌دهنده خدمت، بر اساس قابلیت‌های مشخص و قابل آزمون ارزیابی می‌شود. این قابلیت‌ها می‌توانند شامل ثبت داده‌های الزامی، رعایت مدل‌های اطلاعاتی، پشتیبانی از APIهای مصوب، انطباق با پروفایل‌های FHIR، رعایت قواعد امنیتی، ثبت منشأ داده و ارائه اطلاعات مورد نیاز برای شاخص‌های ملی باشند.

نکته مهم این است که پذیرش در بازارگاه نباید به یک ادعای کلی مانند «پشتیبانی از FHIR» یا «قابلیت اتصال به سامانه ملی» محدود شود. لازم است آزمون‌های انطباق روشن، سناریوهای اجرایی و معیارهای قابل تکرار تعریف شوند.

برای نمونه، یک مرکز درمان ناباروری باید بتواند اطلاعات مشخصی را مطابق قرارداد مصوب ارسال کند؛ سامانه مقصد باید داده را از نظر ساختار و قواعد معنایی اعتبارسنجی کند؛ رویداد تبادل باید ثبت شود؛ و اطلاعات منتخب، پس از عبور از کنترل‌های کیفیت، در لایه تحلیلی قابل استفاده باشد.

این سناریو نه‌تنها قابلیت فنی محصول، بلکه عملکرد زنجیره تبادل و سازگاری آن با معماری ملی را نیز می‌آزماید.

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

همچنین، لازم است میان سه سطح تمایز قائل شد:

۱. انطباق محصول: آیا سامانه الزامات فنی، اطلاعاتی، امنیتی و عملکردی تعیین‌شده را برآورده می‌کند؟

۲. انطباق اتصال: آیا سامانه در تبادل واقعی داده با خدمات و زیرساخت‌های ملی، قراردادها و قواعد مصوب را رعایت می‌کند؟

۳. صلاحیت بهره‌برداری: آیا شرایط قانونی، سازمانی، امنیتی و عملیاتی لازم برای استفاده از محصول در محیط مشخص فراهم است؟

این تفکیک مانع از آن می‌شود که یک گواهی فنی، به‌اشتباه معادل تضمین کیفیت همه فرایندهای اجرایی یا شرایط بهره‌برداری تلقی شود.

۸. پیوند با ماده ۶۹ قانون برنامه هفتم پیشرفت

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

در چارچوب مورد بحث این مقاله، جزء (۱) بند (الف) و جزء (۴) ماده ۶۹ قانون برنامه هفتم، دو جهت‌گیری مکمل را پیش روی نظام سلامت قرار می‌دهند: از یک سو، توسعه نقشه راه و ظرفیت‌های سلامت الکترونیک و از سوی دیگر، شکل‌دهی به سازوکارهای تنظیم‌گری و عملیاتی سلامت دیجیتال.

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

سامانه باروری سالم می‌تواند چنین نقشی ایفا کند.

از منظر نقشه راه سلامت الکترونیک، این پروژه فرصتی برای آزمودن معماری چندلایه، مدل‌های اطلاعاتی استاندارد، تبادل مبتنی بر FHIR، پیوند منطقی پرونده‌ها و بهره‌برداری تحلیلی از داده‌ها فراهم می‌آورد.

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

در این چارچوب، دستاورد پروژه تنها یک سامانه تخصصی نخواهد بود؛ بلکه مجموعه‌ای از اسناد، استانداردها، ابزارهای آزمون، مدل‌های داده، قواعد حکمرانی و قابلیت‌های نرم‌افزاری تولید می‌شود که در پروژه‌های بعدی نیز قابل استفاده‌اند.

برای آنکه این ارتباط از سطح یک استدلال مفهومی فراتر رود، لازم است در اسناد اجرایی پروژه، خروجی‌های فنی و انطباقی به‌صورت صریح تعریف شوند. از جمله:

• معماری مرجع چندلایه و مستندات طراحی؛

• پروفایل‌ها و قراردادهای ملی FHIR برای دامنه باروری سالم؛

• واژگان، کدگذاری‌ها و قواعد اعتبارسنجی مورد نیاز؛

• مجموعه APIهای مصوب و مستندات آزمون آنها؛

• مدل تحلیلی و فرهنگ شاخص‌های ملی؛

• سازوکارهای امنیت، دسترسی و ممیزی؛

• چارچوب آزمون انطباق محصولات متصل به بازارگاه؛

• الگوی عملیاتی انتقال و توسعه معماری به سایر حوزه‌های سلامت.

بدین ترتیب، سامانه باروری سالم می‌تواند به یک پروژه پیشران تبدیل شود؛ پروژه‌ای که هم تکالیف تخصصی قانون حمایت از خانواده و جوانی جمعیت را پشتیبانی می‌کند و هم بخشی از زیرساخت مشترک مورد نیاز برای تحقق سیاست‌های سلامت دیجیتال کشور را به‌صورت قابل ارزیابی توسعه می‌دهد.

۹. الزامات موفقیت: چگونه از تبدیل پروژه به یک سامانه جزیره‌ای جلوگیری کنیم؟

تحقق این چشم‌انداز به انتخاب یک فناوری خاص یا خرید یک محصول نرم‌افزاری وابسته نیست. مهم‌تر از فناوری، تصمیم‌های معماری و حکمرانی است که در آغاز پروژه اتخاذ می‌شوند.

۹ـ۱. تعریف معماری پیش از توسعه محصول

پیش از آغاز توسعه گسترده، باید معماری مرجع، حدود مسئولیت هر لایه، مدل‌های اطلاعاتی، جریان‌های داده و نقاط اتصال با سامانه‌های بیرونی مشخص شوند.

این کار به معنای توقف توسعه عملیاتی تا تکمیل تمام اسناد نیست؛ بلکه به معنای آن است که توسعه بر اساس یک معماری مصوب و قابل تکامل انجام شود.

۹ـ۲. طراحی بر اساس قابلیت‌های مشترک

باید میان قابلیت‌های عمومی و قابلیت‌های تخصصی باروری سالم تمایز گذاشت.

مدیریت هویت، کنترل دسترسی، مدیریت API، ثبت منشأ، اعتبارسنجی داده، انتقال اطلاعات و زیرساخت داشبوردسازی، ظرفیت‌هایی هستند که می‌توانند در حوزه‌های مختلف سلامت مشترک باشند.

در مقابل، مدل اطلاعاتی درمان ناباروری، فرایند مراقبت بارداری و قواعد مرتبط با غربالگری جنینی، نیازمند طراحی تخصصی همان حوزه‌اند.

این تفکیک، امکان استفاده مجدد از اجزای معماری را افزایش می‌دهد و از بازتولید زیرساخت‌های مشابه در هر پروژه جلوگیری می‌کند.

۹ـ۳. تدوین فرهنگ داده و شاخص‌های قابل حسابرسی

داشبورد بدون تعریف معتبر شاخص، می‌تواند تصویری گمراه‌کننده از عملکرد نظام سلامت ارائه دهد.

برای هر شاخص باید منبع داده، صورت و مخرج، جامعه هدف، دوره محاسبه، محدودیت‌های تفسیری و مسئول تأیید مشخص باشد. همچنین، نسخه‌های مختلف تعریف شاخص و تغییرات در روش محاسبه باید ثبت شوند تا مقایسه تاریخی معتبر باقی بماند.

۹ـ۴. حفاظت از حریم خصوصی از مرحله طراحی

اطلاعات باروری، بارداری و تصمیم‌های حساس پزشکی، نیازمند حفاظت متناسب با میزان حساسیت هستند.

بنابراین، باید اصل حداقل دسترسی، تفکیک محیط‌های عملیاتی و تحلیلی، ثبت دسترسی‌ها، حفاظت از شناسه‌ها، مدیریت مجوزها و استفاده مسئولانه از داده‌های تجمیعی از ابتدا در معماری لحاظ شود.

استفاده از داده برای تحلیل مدیریتی نباید به دسترسی نامحدود مدیران به اطلاعات هویتی منجر شود. نیاز به مشاهده شاخص یک مرکز، الزاماً به معنای نیاز به مشاهده پرونده تک‌تک افراد نیست.

۹ـ۵. اجرای مرحله‌ای و آزمون‌پذیر

بهتر است پروژه با چند سناریوی انتهابه‌انتها آغاز شود؛ سناریوهایی که کل زنجیره را از ثبت داده در مبدأ تا تبادل استاندارد، اعتبارسنجی، ذخیره پایدار و تولید شاخص آزمایش کنند.

برای مثال، یک سناریو می‌تواند به ثبت و پیگیری مراقبت مادر باردار اختصاص یابد؛ سناریوی دیگر، تبادل اطلاعات منتخب درمان ناباروری؛ و سناریوی سوم، تولید یک مجموعه شاخص مدیریتی از داده‌های چندمنبعی.

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

۹ـ۶. تفکیک مسئولیت سیاست‌گذاری، اجرا و ارزیابی

برای پایداری پروژه، نقش‌ها باید روشن باشند. مرجع سیاست‌گذار باید الزامات و قواعد را تصویب کند؛ متولی فنی باید معماری و زیرساخت را توسعه دهد؛ ارائه‌دهندگان خدمات باید داده‌های معتبر تولید کنند؛ و ارزیابی انطباق باید بر اساس معیارهای شفاف و قابل تکرار انجام شود.

در موارد لازم، ارزیابی مستقل محصولات و اتصالات نیز باید از توسعه و بهره‌برداری آنها تفکیک شود تا اعتبار نتایج آزمون حفظ شود.

۱۰. نقشه راه پیشنهادی برای تحقق پروتوتایپ ملی

برای تبدیل این ایده به یک پروژه اجرایی، می‌توان مسیر توسعه را در پنج مرحله تعریف کرد.

مرحله نخست: تدوین معماری و الزامات

در این مرحله، مواد قانونی مرتبط به نیازمندی‌های داده‌ای و عملیاتی نگاشت می‌شوند. ذی‌نفعان، سامانه‌های مبدأ، جریان‌های اطلاعاتی، مدل‌های داده، نیازهای امنیتی و شاخص‌های اولیه شناسایی می‌شوند. خروجی اصلی، معماری مرجع و نقشه راه پیاده‌سازی است.

مرحله دوم: طراحی مدل اطلاعات و قراردادهای تبادل

در این مرحله، مدل دامنه باروری سالم، پروفایل‌های FHIR، واژگان و کدگذاری‌ها، شناسه‌ها، قراردادهای API و قواعد اعتبارسنجی تعریف می‌شوند. همچنین، الزامات انطباق برای سامانه‌هایی که قرار است به زیست‌بوم متصل شوند، تدوین می‌شود.

مرحله سوم: استقرار زنجیره داده و مخزن تحلیلی

در این مرحله، انتقال کنترل‌شده داده از منابع منتخب، کیفیت‌سنجی، مدیریت منشأ، تطبیق شناسه‌ها و سازمان‌دهی داده‌ها در لایه پایدار اجرا می‌شود. انتخاب فناوری و مدل تحلیلی باید بر اساس نیازهای واقعی و ظرفیت‌های زیرساختی انجام شود.

مرحله چهارم: تولید داشبوردها و آزمون انطباق

در این مرحله، شاخص‌های مصوب پیاده‌سازی می‌شوند و صحت محاسبات آنها با داده‌های آزمون و نمونه‌های قابل بررسی سنجیده می‌شود. هم‌زمان، آزمون‌های انطباق برای تبادل ساختاری و معنایی، امنیت و قابلیت ردیابی اجرا می‌شوند.

مرحله پنجم: ارزیابی، تثبیت و تعمیم

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

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

۱۱. سنجش موفقیت: چه چیزی باید در پایان پروژه اثبات شود؟

اگر هدف، تبدیل سامانه باروری سالم به پروتوتایپ پایگاه ملی سلامت باشد، ارزیابی پروژه نباید فقط بر تعداد کاربران، تعداد پرونده‌ها یا تعداد داشبوردهای تولیدشده متمرکز شود.

موفقیت باید در چند سطح سنجیده شود:

• سطح حقوقی و فرایندی: میزان پوشش تکالیف قانونی و قابلیت مستندسازی اجرای آنها؛

• سطح داده: کامل بودن، صحت، یکتایی، سازگاری و قابلیت ردیابی اطلاعات؛

• سطح هم‌کنش‌پذیری: موفقیت تبادل ساختاری و معنایی میان سامانه‌های مستقل؛

• سطح تحلیلی: صحت، تکرارپذیری و قابلیت حسابرسی شاخص‌ها؛

• سطح امنیت: رعایت سیاست‌های دسترسی، ثبت رویدادها و حفاظت از اطلاعات حساس؛

• سطح بازارگاه: قابلیت آزمون و پذیرش محصولات بر اساس معیارهای مشترک؛

• سطح توسعه‌پذیری: میزان استفاده مجدد از اجزای معماری در حوزه‌های دیگر.

برای نمونه، باید بتوان نشان داد که یک شاخص مشخص، از داده‌های مبدأ تا داشبورد مدیریتی، زنجیره‌ای قابل ردیابی دارد؛ تعریف آن مستند است؛ محاسبه‌اش تکرارپذیر است؛ و تغییر در یک سامانه مبدأ، بدون کنترل و ثبت تغییرات، به‌طور پنهان معنای شاخص را تغییر نمی‌دهد.

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

چنین معیارهایی کمک می‌کنند تا پروژه از یک موفقیت صرفاً اجرایی به یک موفقیت معماری و نهادی تبدیل شود.

۱۲. نتیجه‌گیری: یک فرصت قانونی برای ساختن الگوی ملی

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

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

پیشنهاد اصلی مقاله آن است که مرکز مدیریت آمار و فناوری اطلاعات وزارت بهداشت، سامانه باروری سالم را فرصتی برای توسعه یک نمونه عملیاتی از معماری پایگاه ملی سلامت و الگوی مدیریت بازارگاه سلامت دیجیتال کشور تلقی کند.

در این رویکرد، سامانه‌های عملیاتی مسئول ارائه خدمت و ثبت تراکنش‌ها باقی می‌مانند؛ استانداردهای FHIR و سازوکارهای ملی تبادل، هم‌کنش‌پذیری را امکان‌پذیر می‌کنند؛ لایه رسوب پایدار، امکان حفظ و سازمان‌دهی داده‌های تاریخی را فراهم می‌آورد؛ و معماری تحلیلی مبتنی بر OLAP، داده‌ها را به شاخص‌ها، داشبوردها و شواهد مدیریتی تبدیل می‌کند.

این معماری در کنار سازوکارهای حکمرانی، امنیت و حفاظت از داده، می‌تواند زیرساختی مشترک برای ارزیابی انطباق محصولات و اتصال تدریجی آنها به بازارگاه سلامت دیجیتال ایجاد کند.

مزیت چنین الگویی در آن است که هر هزینه‌ای که برای استانداردسازی مدل داده، تعریف قراردادهای تبادل، توسعه ابزارهای اعتبارسنجی، مدیریت منشأ یا ایجاد لایه تحلیلی صرف می‌شود، بالقوه می‌تواند در پروژه‌های بعدی نیز ارزش‌آفرینی کند. به این ترتیب، توسعه یک سامانه موضوعی به سرمایه‌گذاری زیرساختی برای کل نظام سلامت تبدیل می‌شود.

البته این نتیجه خودکار نیست. اگر پروژه به توسعه یک نرم‌افزار متمرکز، ذخیره‌سازی اختصاصی داده‌ها و گزارش‌گیری‌های موردی محدود بماند، صرف نام‌گذاری آن به‌عنوان سامانه ملی یا استفاده از یک استاندارد فنی، آن را به پروتوتایپ پایگاه ملی سلامت تبدیل نخواهد کرد.

آنچه این تبدیل را ممکن می‌سازد، تعهد روشن به معماری چندلایه، استانداردهای قابل آزمون، تفکیک عملیات از تحلیل، حکمرانی داده، قابلیت توسعه و ارزیابی مستقل است.

در نهایت، سامانه باروری سالم می‌تواند نمونه‌ای باشد از اینکه چگونه یک تکلیف قانونی مشخص، در صورت اجرای درست، به فرصتی برای ارتقای ظرفیت نهادی و فناورانه کشور تبدیل می‌شود؛ فرصتی برای گذار از تعدد سامانه‌های جزیره‌ای به یک زیست‌بوم هم‌کنش‌پذیر، از ثبت داده به تولید شواهد و از توسعه نرم‌افزارهای منفرد به استقرار زیرساخت مشترک سلامت دیجیتال.

دستاورد راهبردی این پروژه، صرفاً راه‌اندازی سامانه باروری سالم نیست؛ بلکه اثبات امکان ساختن پایگاه ملی سلامت از مسیر پروژه‌های واقعی، استانداردمحور و قابل تعمیم است. اگر این الگو به‌درستی طراحی و اجرا شود، باروری سالم می‌تواند نه‌فقط یکی از حوزه‌های بهره‌مند از تحول دیجیتال، بلکه یکی از نخستین پیشران‌های تحقق آن در نظام سلامت ایران باشد.