بعد از دیدن تیتر این مقاله شاید این سوال برای شما پیش آمده باشد که API ها در حوزه سلامت چه کاربردی دارند؟ ما در ادامه سری مقالاتی که از سایت HBR ترجمه کردیم به این موضوع پرداختیم. با توجه به توسعه سریع تکنولوژی و همگامی آن با اتفاقات روز پرداختن به نحوه همگام‌سازی و جمع‌آوری داده‌ها با کمک API ها و در حوزه سلامت بسیار جالب توجه است. بعد از شیوع بیماری کرونا و در پی آن شروع واکسیناسیون یک چالش جدید بوجود آمد. ما گزینه‌های زیادی برای ذخیره و دسترسی به اطلاعات واکسیناسیون کرونا نداشتیم. در نهایت شاید یک کارت واکسن کاغذی که برای جا دادن در کیف پول خیلی بزرگ است یا یک عکس بی کیفیت در گوشی موبایل یا یک کارت واکسیناسیون الکترونیکی که از طریق QR کد قابل نمایش است. این عکس ممکن است فقط شامل اطلاعات تزریق دو دوز از واکسن باشد و اطلاعات دوز سوم در آن بروزرسانی نشده باشد.
در عصری که اپلیکیشن‌های بانکی به طور معمول تمام اطلاعات مالی ما را جمع‌آوری می‌کنند و رستوران مورد علاقه ما می‌تواند هنگام سفارش آنلاین «سفارش همیشگی» ما را به خاطر بسپارد، عجیب است که یک تکه مقوا تنها مدرک برای اثبات واکسیناسیون بسیاری از افراد است.
کارت‌های واکسیناسیون تنها بخش کوچکی از یک مشکل بزرگ‌تر هستند. اطلاعات سلامت افراد معمولا در بیمارستان‌ها، کلینیک‌ها و داروخانه‌ها پخش شده است. بخش بزرگی از تاریخچه پزشکی افراد به هر نحوی در هنگام نقل مکان یا تغییر پزشک از بین می‌رود، چون انتقال اطلاعات آن‌ها بسیار پیچیده است. اگر شما به تمام سابقه پزشکی خود در یک سیستم جامع دسترسی دارید باید گفت که خوش شانس هستید چون در بیشتر مواقع چنین امکانی وجود ندارد.
فراهم‌کنندگان خدمات بهداشتی و درمانی هم با چنین مشکلاتی مواجه هستند. حتی زمانی که آن‌ها از یک نرم‌افزار برای دسترسی به پرونده الکترونیک سلامت افراد استفاده می‌کنند، سیستم‌های درمانی همیشه نمی‌توانند به راحتی اطلاعات را به اشتراک بگذارند. تلاش برای دسترسی به یک پرونده واکسیناسیون از یک شهر دیگر یا گزارشی از اتاق اورژانس خارج از ایالت، گاهی امکان پذیر و گاهی چالش برانگیز است. در آمریکا تبادل اطلاعات سلامت (HIEs) در بسیاری از ایالت‌ها فعال است و به استفاده کنندگان اجازه می‌دهد تا اطلاعات جمعیتی و سوابق پزشکی را به اشتراک بگذارند، اما از رویکرد نظر سودمندی و در دسترس بودن چالش برانگیز است.
با این حال، تغییرات اجباری از سمت ایالت‌ها در حال انجام است تا اشتراک‌گذاری اطلاعات پزشکی به صورت الکترونیکی ساده‌تر شود و با تکیه بر توانایی‌ها فراهم شده نه تنها به همه اجازه دسترسی به اطلاعات کامل، جامع و آسان مربوط به سلامت اشخاص را می‌دهد، بلکه راه‌های جدید و بی‌شماری را برای استفاده از آن اطلاعات باز می‌کند.
خلاصه‌ای از موانع تاریخی در به اشتراک‌گذاری اطلاعات سلامت
چرا به اشتراک‌گذاری اطلاعات سلامت بسیار نامنظم است، در حالی که تقریبا همه داده‌های سلامت کامپیوتری هستند؟ آیا کامپیوترها نمی‌توانند با یکدیگر ارتباط برقرار کنند؟ در سایر صنایع برای این مشکل راه‌حل‌هایی در نظر گرفته شده است. چرا در حوزه سلامت این اتفاق نیفتاده است؟ آیا می‌توان از API ها در حوزه سلامت استفاده کرد؟
این اتفاق دلایل متعدد و پیچیده دارد، اما مهم ترین لیل را می‌توان در بی‌انگیزگی خلاصه کرد. در خطوط مقدم، متخصصان بالینی دوست دارند به راحتی به اطلاعات مورد نیازشان دسترسی داشته باشند، اما در قسمت اجرایی، این ضرورت به اندازه کافی با اهمیت نبوده است تا سرمایه‌گذاری در آن را توجیه کند. برای بعضی از تامین‌کنندگان نگهداری اطلاعات بیماران یک مزیت رقابتی و یکی از راه‌های جلوگیری از انتقال آن‌ها به یک تامین‌کننده دیگر است. بعضی از کلینیک‌ها و بیمارستان‌ها هنوز هم با دادن یک CD یا یک برگه چاپی به بیمار، با بی‌میلی اطلاعات به اشتراک می‌گذارند.
حتی فرایند سیستمی کردن اولیه اطلاعات پزشکی هم خیلی کند پیش می‌رفت تا این که میلیاردها دلار بودجه فدرال برای به سرانجام رساندن پرونده‌های سلامت الکترونیکی در دولت اوباما در سال ۲۰۰۹ تصویب شد، این کار معادله سرمایه‌گذاری را تغییر داد. وادار کردن تعداد زیادی از تامین‌کنندگان به انجام این کار، نیاز به بودجه کافی داشت.
ارسال اطلاعات و سوابق سلامت از یک کامپیوتر به کامپیوتر دیگر، تاریخچه پرفراز و نشیب خود را دارد. بسیاری از فروشندگان نرمافزارهای حوزه مراقبت‌های سلامت با درست کردن نرمافزارهای سفارشی برای اتصال سیستم‌های متنوعی که در بسیاری از بیمارستان‌ها مورد استفاده قرار می‌گیرند، باعث می شدند که در صورت نیاز به اعمال تغییرات در سیستم بیمارستان با هزینه‌های زیادی روبرو می‌شد. این موضوع برای شرکت‌های نرم‌افراز تبدیل به یک تجارت پرسود شده بود.
علاوه بر این، شرکت‌های نرم‌افزار اغلب با جلوگیری از قابلیت انتقال داده، از این موضوع به عنوان یک استراتژی برای حفظ مشتری استفاده می‌کردند. اگر انتقال داده‌های بیمارستان به سیستم یا نرم‌افزار دیگری دشوار یا پرهزینه باشد، آن‌ها به صورت پیشفرض از نسخه‌ای که دارند، استفاده می‌کنند. در عین حال بعضی از شرکت‌های نرم افزاری گام‌هایی را برای کمک به بیمارستان ها در جهت اشتراک گذاری خدمات برداشته‌اند.
به عنوان مثال، فروشندگان EHR به مشتریان خود اجازه می‌دهد تا در صورت موافقت دوجانبه، داده‌ها را به راحتی مبادله کنند. اما نمی‌تواند آن‌ها را بسازند. اگر دو مشتری در یک بازار معین با هم رقابت کنند، ممکن است، تصمیم بگیرند که این کار به نفع آن‌ها نیست، حتی اگر به نفع بیمارانشان باشد.
این بدان معنا نیست که صنعت مراقبت بهداشتی فاقد استانداردهای داده است؛ کاملا برعکس. اما آن‌ها اغلب توسط گروه‌هایی ایجاد می شوند که به انواع خاصی از داده‌ها علاقه دارند. برای مثال، استانداردهایی که برای تصویربرداری پزشکی، توسط کالج آمریکایی رادیولوژیست‌ها ایجاد شده است. آن‌ها تا حدودی آشفتگی‌هایی که در اشتراک‌گذاری داده‌ها بود، کم‌تر کردند، اما همچنان نمی‌توانند مسائل دیگری که در مورد آن بحث کردیم را حل کنند.
در این شرایط، بیماران گیج می‌شوند و نمی‌توانند به هیچ روشی به اطلاعات جامع خود دسترسی داشته باشند. همه چیز احتمالاً در جایی روی کامپیوتر است، اما هنوز هیچ نیرویی وجود ندارد که آنقدر قدرتمند باشد که بتواند آن‌ها را در یک جا تجمیع و پیدا کردن آن‌ها را آسان کند، چه برسد به این که از آن‌ها برای بهبود شرایط سلامتی استفاده کرد.
دولت فدرال وارد عمل شد
برای حل مشکلات داده ها در حوزه سلامت دولت فدرال را درگیر این موضوع شد، احزاب قدرت کافی برای ایجاد تغییر واقعی در حوزه مراقبت‌های بهداشتی و سلامتی در آمریکا را دارد. دولت برای حمایت از حوزه سلامتی، از سیستم بیمه کمک گرفت و برای مراقبت‌های پزشکی برای افراد ۶۵ سال و بالاتر، بیمه درمانی برای فقرا، بیمه درمانی کودکان، سیستم مراقبت‌های سلامت برای سربازان قدیمی، بیمه وزارت دفاع برای پرسنل نظامی و بیمه سلامت برای میلیون‌ها کارمند فدرال و خانواده‌های آن‌ها هزینه پرداخت می‌کند.
در روزهای پایانی دولت اوباما، او با استفاده از نفوذ خود، سرانجام قانون درمان قرن ۲۱ را با گنجاندن الزامات مشخص برای تبادل آسان داده‌های سلامتی تا پایان سال ۲۰۲۲ تصویب کرد. تامین‌کنندگانی که از این الزامات پیروی نمی‌کنند ممکن است نتوانند در مشارکت و استفاده بیمه مراقبت‌های پزشکی سهیم باشند و این حجم از ضرر برای اکثر بیمارستان‌ها و پزشکان ویرانگر است. آن‌ها به فروشندگان نرم‌افزار خود وابسته هستند تا آنچه را که مورد نیاز است، انجام دهند و آن‌ها را از قرار گرفتن در یک چالش جدی نجات دهند.
این قانون همچنین برای فروشندگان، تامین‌کنندگان و پرداخت‌کنندگانی که از شیوه‌های “مسدود کردن اطلاعات” استفاده می‌کنند، هم مجازاتی تعیین کرده است.
حالا این سوال مرح است که از آن جایی که پایان سال ۲۰۲۲ چندان دور نیست، صنعت مراقبت‌های سلامتی چگونه این ماموریت را انجام می‌دهد؟ با انجام کاری که از مدت‌ها پیش می‌دانست و نیازی به دستور از سوی دولت فدرال برای انجام آن نبود: استفاده یک روش استاندارد برای ایجاد ارتباط بین کامپیوترها
قدرت API ها
این روش application programming interfaces یا API ها نامیده می‌شود و با کمک آن دستگاه‌ها و برنامه‌های نرم‌افزاری شما می‌توانند، بدون این که شما کاری انجام دهید، اطلاعات را مبادله کنند. API ها از قابلیت‌های یک اپلیکیشن برای خواندن و نوشتن داده‌ها در برنامه یک برنامه‌نویس دیگر پشتیبانی می‌کنند.
API ها همه جا هستند. اگر اطلاعات همه حساب‌های بانکی و کارت اعتباری خود را در یک اپلیکیشن برنامه‌ریزی مالی جمع‌آوری کرده‌اید، این API ها بودند که این کار را انجام دادند. API ها به شما امکان می‌دهند از اطلاعات حساب گوگل یا فیسبوک خود، برای ورود به وب سایت‌های متعلق به فیسبوک و یا گوگل استفاده کنید. API ها دلیلی هستند که می‌توانید از وب‌سایت یک شرکت به اپلیکیشن آن بروید و دوباره برگردید و از جایی که توقف کرده‌اید، دوباره ادامه دهید.
برای مثال، هر کسی می‌تواند یک کارت واکسیناسیون الکترونیکی در تلفن خود داشته باشد که به‌طور خودکار بروزرسانی می‌شود، حتی اگر از یک تامین‌کننده متفاوت برای هر واکسن استفاده شده باشد. استفاده از API برای پرونده الکترونیکی سلامت می‌تواند به مردم امکان دسترسی آسان و کارآمد به داده‌های را برای کمک به آن‌ها برای درک وضعیت سلامت و انتخاب آگاهانه‌تر دهد.
تامین‌کنندگان باید تصویر کاملی از تاریخچه هر بیمار داشته باشند. آن‌ها می‌توانستند از این اطلاعات نه تنها برای پشتیبانی در تصمیم‌گیری بالینی خود، بلکه به عنوان بخشی از تجزیه و تحلیل سلامت جامعه و پیدا کردن الگو در جامعه بیمارانشان استفاده کنند. با این روش محققان به راحتی می‌توانند بیمارانی را شناسایی کنند که ممکن است در یک آزمایش بالینی خاص به آن‌ها کمک کنند. این موضوع یکی از کاربردهای داده‌ها برای کشف و ارزیابی داروها و درمان‌های جدید است.
FHIR : کتابچه راهنمای API آموزش بهداشت و درمان
API های استاندارد نیاز به یک سند استاندارد دارند که فرمت داده‌ها و مقادیر مجاز برای هر منبع یا نوع داده‌ای که باید تبادل شود را مشخص کند. این استاندارد می‌تواند به سادگی مشخص کردن این باشد که تمام تاریخ‌ها در فرمت mm / dd / yy خواهند بود، اگرچه انواع پیچیده‌تر داده‌ها متقابلا استانداردهای پیچیده‌تری خواهند داشت. حوزه مراقبت سلامت انواع مختلفی از داده‌ها را ایجاد می‌کند و از داده‌های خیلی ساده تا انواع بسیار پیچیده را شامل می‌شود. پس برای اجرایی کردن آن به یک دستورالعمل مفصل و دقیق نیاز دارد.
این کتابچه راهنما (Fast Healthcare Interoperability Resource (FHIR نامیده می‌شود، کتابچه‌ای است که قوانین درمانی را در قرن ۲۱ مشخص کرده است و برای تسهیل در انجام همکاری که در بالا توضیح دادیم تا پایان سال جاری استفاده شود.
چرا FHIR تاییدیه فدرال را گرفته است؟
نظارت قوی
FHIR از طریق (Health Level Seven International (HL7 که یک سازمان توسعه استانداردهای مراقبت‌های بهداشتی است که در سال ۱۹۸۷ تاسیس شده است، مدیریت و توسط هر بازیگر مهمی در حوزه فعالیت فناوری اطلاعات سلامت (با زمان، تخصص و پول کارکنان) حمایت می‌شود. HL7 دارای بیش از ۵۰۰ عضو شرکتی و سازمانی است، از جمله:
- فروشندگان فناوری اطلاعات سلامت (مانند Epic، Cerner، و Athena Health)
- سازمان‌های دولتی (مانند مراکز مراقبت‌ها و خدمات پزشکی، مراکز کنترل و پیش‌گیری از بیماری‌ها، اداره غذا و دارو، وزارت امور سربازان قدیمی ایالات‌متحده، موسسات ملی بهداشت، و آژانس پزشکی اروپا)
- سیستم‌های بهداشتی (مانند Mayo Clinic, Mass General Brigham, Kaiser Permanente, University of Pittsburgh Medical Center, and Intermountain Healthcare)
- برنامه‌های بهداشتی ( مانند Humana، Anthem، Aetna، Optum، Centene، Blue Cross Blue Shield Association، UnitedHealthcare، و Cigna)
- شرکت‌های فن‌آوری اطلاعات (مانند اپل، مایکروسافت و گوگل)
- شرکت‌های فن‌آوری و خدمات بهداشت و درمان (مانند Accenture، CVS Health، Pfizer، Philips، و Quest Diagnostics)
- سازمان‌های حرفه‌ای (مانند انجمن پزشکی آمریکا، کالج پزشکان آمریکایی، انجمن ملی مراکز بهداشت جامعه، و کمیته ملی تضمین کیفیت)
HL7 از زمان شروع توسعه در سال ۲۰۱۱، کنترل دقیقی بر استانداردهای FHIR داشته است. این کنترل مهم است زیرا از ایجاد مشکلات مکرر در توسعه استانداردها و مواردی مانند بوجود آمدن استثناها برای استاندارد، جلوگیری می‌کند.
HL7 یک مجموعه قوی از خدمات را برای پشتیبانی از اجرای FHIR توسعه داده‌است. این خدمات شامل بسترهای آزمایشی، برنامه‌های آموزشی، و راهنماهای اجرایی هستند. پذیرش و استفاده از استانداردها، نیاز به طراحی مناسب این استانداردها و پشتیبانی قوی برای اجرای آن‌ها دارد.
پذیرش بین‌المللی
FHIR برای تبدیل شدن به یک استاندارد جهانی، نه فقط برای استفاده در آمریکا آماده شده است. برای برنامه‌نویسان این طرح، این ارزش، پذیرش استانداردها را افزایش می‌دهد. اسناد کامل FHIR در حال حاضر علاوه بر انگلیسی به زبان‌های روسی، چینی و ژاپنی نیز موجود است.
استفاده موفقیت‌آمیز فعلی
در حال حاضر از FHIR مورد استقبال واقع شده و استفاده از آن ایجاد ارزش می‌کند.
- یک نظرسنجی در سال ۲۰۱۹ نشان داد که ۸۴٪ از بیمارستان‌ها و ۶۱٪ از پزشکان، فناوری API تایید شده با FHIR را پذیرفته و آن را اجرا کردند.
- کیت‌های توسعه نرم افزار اپل از FHIR پشتیبانی می‌کنند. صدها سیستم بهداشتی، اپلیکیشن‌هایی آماده کرده‌اند که بیماران با کمک آن بتوانند، اطلاعات سلامتی خود را با استفاده از این فناوری اپل جمع‌آوری کرده و به آن‌ها دسترسی داشته باشند.
- جامعه توسعه اپلیکیشن‌ها، از جمله اپل، گوگل و مایکروسافت، به طور فعال از یک استاندارد ویژه و برنامه به نام SMART در FHIR ، برای ساختن اپلیکیشن‌های سازگار با FHIR استفاده می‌کنند.
- کلینیک مایو دریافته است که API ها در FHIR می‌توانند تا دو برابر، زمان و هزینه توسعه رابط‌های بین اپلیکیشن‌ها را کاهش دهند.
تسریع در انتقال
HL7 چندین شتابدهنده با هدف تبادل اطلاعات در بخش‌های مختلف حوزه مراقبت‌های سلامت را تشکیل داده است. اولین پروژه Argonaut بود که در سال ۲۰۱۴ برای توسعه بلوک‌های سازنده اصلی استانداردهای FHIR تاسیس شد.
در هر شتابدهنده، توسعه‌دهندگان و کاربران همکاری می‌کنند تا «use cases» ها که تبادل اطلاعات پیشنهادی در آن‌ها اتفاق می‌افتد و استانداردهای داده‌ای مورد نیاز برای پشتیبانی از این use cases را تعریف کنند. شتاب‌دهنده‌های HL7 همچنین راهنماهایی را برای پشتیبانی از اجرای استانداردهایی که برای فروشندگان در تولید محصولات نرم‌افزاری یا ترکیب ویژگی‌های جدید، در محصولات موجود، آماده کرده است.
شرکا بودجه کارهای‌های انجام شده در شتاب‌دهنده‌ها را تامین می‌کنند و در چارچوب دستورالعمل‌های HL7، نحوه عملکرد این شتابدهنده را تعیین می‌کنند.
به عنوان مثال :
- CodeX به نیازهای تحقیقاتی سرطان، مانند انجام آزمایش‌های بالینی با استفاده از «داده‌های دنیای واقعی» و جمع‌آوری‌شده از EHR و تطبیق بیماران با آزمایش‌های بالینی می‌پردازد.
- پروژه داوینچی بر تعامل بین تامین‌کنندگان مراقبت‌های بهداشتی و برنامه‌های بهداشتی متمرکز است: مجوزهای قبلی، تأیید پوشش بیمه سلامت بیمار و دسترسی به اطلاعات در مورد هزینه‌های مراقبت و ..
- پروژه Helios، در پاییز سال ۲۰۲۱ شکل گرفت، بر روی موارد استفاده سلامت عمومی تمرکز می‌کند، از جمله گزارش وقوع بیماری‌هایی مانند COVID۱۹، آنفولانزا، و بیماری‌های مقاربتی تمرکز دارد.
پذیرش گسترده FHIR در مراحل اولیه خود است. با این حال، ما فکر می‌کنیم که با توجه به پتانسیل بالا FHIR، نوید وعده‌های زیادی می‌دهد:
- استانداردها با حمایت مناسب و خوب تعریف شده
- داشتن حکم فدرال برای اجرای API ها در تمام برنامه‌هایی که به اطلاعات بهداشتی رسیدگی می‌کنند
- طیف گسترده‌ای از موارد استفاده برای هر جنبه از مراقبت‌های بهداشتی
- تعهد طیف وسیعی از شرکا در صنعت
واضح است که تا پایان سال جاری، مردم از دسترسی فوری و یکپارچه به تمام اطلاعات بهداشتی خود لذت نخواهند برد. سازگاری جهانی FHIR یک خط مبنا است، نه خط پایان. استانداردها هنوز در حال توسعه هستند. سیستم‌های قدیمی باید با API های FHIR تجهیز شوند. همه پایگاه‌هایی که داده‌های سلامت را مدیریت می‌کنند باید بتوانند به راحتی آن‌ها را به اشتراک بگذارند.
API های استاندارد می‌توانند جادوی خود را سریع به کار گیرند: فروشگاه اپل که در سال ۲۰۰۸ با ۵۰۰ اپلیکیشن راه‌اندازی شد و امروزه ۲ میلیون برنامه دارد. فروشگاه Google Play هم که در همان سال راه اندازی شد تقریباً ۳ میلیون برنامه دارد.
در حالی که صنعت نرم‌افزار مراقبت سلامت، شرکت‌های بانفوذی مانند گوگل یا اپل ندارد، پشتیبانی جهانی که توسط HL7 انجام می‌شود، هدف یکسانی دارد و از بسیاری جهات، همکاری بهتری را در جامعه کاربران ایجاد و تسهیل می‌کند.
برای استفاده از فرصت‌های سرمایه‌گذاری ارائه شده توسط FHIRو API ها در حوزه سلامت تامین‌کنندگان برنامه‌های سلامت و فروشندگان نرم‌افزار باید چندین مرحله را انجام دهند.
- تا جای ممکن در مورد استانداردهای FHIR و مقررات فدرال یاد بگیرید.
سازمان‌ها باید دیدگاه‌های آژانس فدرال درباره FHIR و مقررات مربوطه را بررسی کنند و از منابعی که همیشه این تغییرات مهم را منتشر می‌کنند، استفاده کنند: مانند جلسات، وبینارها و مقالات صنعتی. نشست HIMSS 2022، بزرگ‌ترین گردهمایی فناوری اطلاعات سلامت در جهان است و در آن تقریباً ۴۰ جلسه در مورد جنبه‌های مختلف اجرای FHIR، از اخذ مجوزهای قبلی تا تحقیقات سرطان و شفافیت هزینه مراقبت‌های بهداشتی برگزار می‌کند.
- در برنامه شتابدهنده HL7 FHIR فعال شوید.
این فعالیت‌های توسعه‌ای نیاز به ورودی‌های گسترده‌ای دارند تا مطمئن شوند که استانداردهای موجود برای همه نیازها پاسخگو هستند.
- برنامه‌ها را برای پیاده‌سازی و انتقال رابط‌های قدیمی فعلی به API های FHIR توسعه دهید.
رعایت نکردن قوانین باعث افزایش ریسک مجازات و مشکلات در بازار می‌شود. علاوه بر این با توجه به نکته بعدی API ها پایه‌ای را برای نسل بعدی برنامه‌های مراقبت‌های بهداشتی فراهم می‌کنند.
- برای شناسایی و ارزیابی کاربردهای جدیدی که FHIR آن‌ها را تسهیل می‌کند، آماده باشید.
موجی از نوآوری، اجرای FHIR را برای رسیدگی به هر مشکلی که می‌تواند با جریان یافتن اطلاعات، بهتر حل شود را همراهی خواهد کرد. اما به یاد داشته باشید، API های FHIR خط مبنا هستند، و هر راه‌حل جدیدی به همان میزان، نیاز به پشتکار دارد.
دستورات جدید فدرالی با حذف موانع تکنولوژیکی و تجاری دشوار، بهبود جریان اطلاعات سلامت را ممکن می‌سازد. این فرایند باعث پیشرفت سریع‌تر برنامه‌های حوزه سلامت خواهد شد.
FHIR و استفاده از API ها در حوزه سلامت در اجرای هر برنامه‌ای را که به اشتراک‌گذاری اطلاعات پیچیده مانند تطبیق اطلاعات اهداکنندگان یا گیرندگان عضو و یا شناسایی موقعیت‌هایی که خطر مرگ و میر مادران در آن بالا است، سرعت می‌بخشد.
این پست ترجمه‌ای است از مقاله
Standardized APIs Could Finally Make It Easy to Exchange Health Records منتشر شده در وب‌سایت HBR است.
دیدگاهتان را بنویسید