قم ببناء مسار وكيل لمطالبات الرعاية الصحية للرعاية الصحية باستخدام الذكاء الاصطناعي مع Amazon Bedrock وAWS HealthLake

لا تزال معالجة النماذج الورقية يدويًا تمثل تكلفة كبيرة في صناعة الرعاية الصحية. على الرغم من التقدم في استخراج البيانات من المستندات والصور الممسوحة ضوئيًا، إلا أن الإشراف البشري لا يزال مطلوبًا في العادة. لا يزال يتعين معالجة خطأ الإدخال من قبل الفرد الذي أنشأ النموذج أو عمليات الاستخراج ذات الثقة المنخفضة من الرقمنة.

في هذا المنشور، نوضح لك كيفية إنشاء مسار معالجة المطالبات المؤتمتة باستخدام اثنين من إمكانيات Amazon Bedrock الرئيسية: Amazon Bedrock Data Automation لاستخراج المستندات الذكية من نماذج مطالبات الرعاية الصحية، وAmazon Bedrock AgentCore لاستضافة وكيل الذكاء الاصطناعي الذي يتحقق من صحة البيانات المستخرجة ويحولها إلى موارد FHIR (موارد سريعة قابلة للتشغيل المتبادل للرعاية الصحية) في AWS HealthLake. سوف تتعلم كيفية الجمع بين هذه الخدمات لإنشاء سير عمل شامل يقلل من المعالجة اليدوية مع الحفاظ على الدقة من خلال عمليات التحقق من الصحة الآلية.

نظرة عامة على الحل

يوضح الحل سير العمل الآلي لمعالجة نماذج مطالبات الرعاية الصحية باستخدام الخدمات المدعومة بالذكاء الاصطناعي. عندما يقوم مقدم رعاية صحية بتحميل نموذج مطالبة CMS-1500 (بتنسيق PDF) إلى حاوية Amazon Simple Storage Service (Amazon S3)، فإنه يؤدي إلى تشغيل مسار معالجة يبدأ بـ AWS Lambda الذي يؤدي ثلاث وظائف رئيسية:

1. تستخرج Amazon Bedrock Data Automation البيانات المنظمة من النموذج باستخدام المعالجة الذكية للمستندات.
2. يقوم وكيل الذكاء الاصطناعي الذي يستخدم Strands Agents الذي يعمل على Amazon Bedrock AgentCore بالتحقق من صحة هذه البيانات مقابل سجلات المرضى ومقدمي الخدمة الموجودة في AWS HealthLake، والتحقق من اكتمالها واتساقها.
3. إذا تم اجتياز جميع عمليات التحقق من الصحة، يقوم الوكيل بإنشاء مورد مطالبة FHIR موحد في HealthLake. كما يقوم أيضًا بإنشاء ملخص فني لمعالجي المطالبات وشرح مناسب للمريض لحالة المطالبة. كلاهما يخرج كإشعارات Amazon Simple Notification Service (Amazon SNS).

يساعد سير العمل الآلي هذا على تقليل وقت المعالجة اليدوية مع الحفاظ على الدقة من خلال التحقق بمساعدة الذكاء الاصطناعي.

الشكل 1: منظر معماري للحل.

ويوضح الرسم البياني السابق الخطوات التالية:

1. يقوم المرسل بتحميل مستند المطالبة إلى Amazon S3.
2. يتم تشغيل AWS Lambda عند وصول الملف.
3. يقوم Amazon Bedrock Data Automation باستخراج المعلومات من المستند وإخراج النتيجة بتنسيق JSON.
4. تقوم AWS Lambda بعد ذلك باستدعاء AgentCore وتمرير المستند للمعالجة.
5. يستعلم AgentCore عن AWS HealthLake، وينشئ المطالبة، وينشئ استجابة JSON ملخصة.
6. تستدعي AWS Lambda Amazon SNS لتقديم استجابة للخطأ أو استجابة ناجحة.

يتم استخدام Lambda كمشغل حدث عند إنشاء مستند في S3 ويعمل كمشرف حتمي على سير عمل الوكيل. إنه يتحقق من صحة معالجة كل مستند أو إرساله إلى قائمة انتظار الرسائل الميتة لمعالجة الاستثناءات.

تعمل تقنية Bedrock Data Automation على تبسيط تطوير الذكاء الاصطناعي التوليدي وأتمتة سير العمل الذي يتضمن المستندات والصور والصوت ومقاطع الفيديو. بالنسبة لمعالجة المستندات، تجمع Bedrock Data Automation بين التعرف البصري التقليدي على الأحرف (OCR)، ونماذج التعلم الآلي (ML)، والذكاء الاصطناعي التوليدي لاستخراج البيانات بدقة. يمكنك استخدام المخططات (المنتجات) لتحديد البيانات المطلوب استخراجها من المستند وكيفية استخراجها. يمكنك استخدام القوالب المعدة مسبقًا أو إنشاء تكوينات مخصصة تناسب حالات الاستخدام الخاصة بك. يتضمن الإخراج درجات الثقة وبيانات المربع المحيط للحقول والجداول المستخرجة. ينتج عن الإخراج المخصص هنا تمثيل JSON يمكن التنبؤ به لنموذج المطالبة CMS-1500 عبر أشكال التنسيق الخاصة به.

يستضيف AgentCore وكيل Strands. يستخدم الوكيل أداتين للتفاعل مع HealthLake: create_fhir_claim و search_fhir_resources.

يستخدم الوكيل سير العمل التالي:

1. ابحث عن معلومات المؤمن عليه والمريض والممارس والتغطية في AWS HealthLake لاستخدامها كمرجع في نموذج المطالبة. تستخدم المحاولة الأولى استدعاءات الطريقة المباشرة ومعلمات البحث الافتراضية. علاوة على ذلك، يقوم الوكيل بتشغيل الموجه التالي للتحقق من استدعاءات الأداة وإعادة محاولة البحث إذا لزم الأمر:
   

   حدد المورد المؤمن عليه، أولاً من خلال النظر في استدعاءات الأداة السابقة. إذا لم يكن هناك تطابق، حاول محاولتين إضافيتين للعثور على تطابق باستخدام معلمات بحث مختلفة من المطالبة JSON. ركز على سمات نقاط الثقة العالية وأبلغ عن كيفية العثور على التطابق.

2. إذا تم العثور على المراجع، فقم بإنشاء تمثيل FHIR للمطالبة وأرسله إلى AWS HealthLake.
3. قم بإنشاء كائن JSON الذي يلتقط العمل المكتمل. يتضمن الكائن معرف المطالبة (إذا تم إنشاؤه)، واستجابة للمعالج البشري، واستجابة للمريض. تعمل استجابة المعالج بمثابة تنبيه أو ملاحظة. تشير استجابة المريض إلى المرسل عندما يلزم تصحيح الأخطاء.

المتطلبات الأساسية

قبل نشر الحل، تأكد من أن لديك ما يلي:

• حساب AWS مع أذونات المسؤول.
• الوصول إلى Anthropic Claude Sonnet 4.6 على Amazon Bedrock. لمزيد من التفاصيل، راجع الوصول إلى نماذج مؤسسة Amazon Bedrock.
• NodeJS الإصدار 24 أو الأحدث.
• Node Package Manager (npm) الإصدار 11.5 أو الأحدث.
• إصدار بايثون 3.13 أو الأحدث.
• AWS Cloud Development Kit (AWS CDK) الإصدار 2.1025 أو الأحدث.

نشر الحل

يتم استخدام AWS Cloud Development Kit (CDK) وواجهة سطر أوامر AgentCore للنشر من خلال الخطوات التالية:

1. استنساخ المستودع:

   git clone https://github.com/aws-samples/sample-agenticidptohealthlake.git

2. قم بتشغيل الأوامر التالية من جذر المستودع:

   npm install
   python -m venv .venv
   source .venv/bin/activate
   pip install -r requirements.txt
   pip install -r requirements.txt --python-version 3.12 --platform manylinux2014_aarch64 --target ./packaging/_dependencies --only-binary=:all:
   cd agentcore
   agentcore configure --entrypoint claimsprocessor.py
   agentcore launch
   python ./bin/package_for_lambda.py
   npx cdk bootstrap
   npx cdk deploy

اشترك في موضوع SNS لتلقي الإخطارات

1. قم بالوصول إلى وحدة تحكم Amazon SNS.
2. يختار المواضيع.
3. يختار إخطارات الوكيل.
4. يختار إنشاء الاشتراك.
5. بالنسبة للبروتوكول، اختر بريد إلكتروني.
6. أدخل عنوان بريدك الإلكتروني.
7. يختار إنشاء الاشتراك.
8. اتبع الرابط الموجود في إشعار التأكيد الموجود في بريدك الإلكتروني لتأكيد اشتراكك.

استخدم الحل

تتناول الأقسام التالية سيناريوهين: سيناريو الفشل وسيناريو النجاح.

1. سيناريو الفشل: قم بمحاكاة الفشل من خلال ترك أحد الموارد المرجعية المطلوبة في AWS HealthLake.

يتضمن رمز المشروع أ sampledata المجلد. يستخدم load_sampledata.py لتنظيم بعض البيانات، حيث <data_store_id> هو HealthLakeDatastoreArn من cdk deploy الإخراج:

python load_sampledata.py <data_store_id> bda_output_insuredid_error.json Patient,Insured,Practitioner

رفع sample1_cms-1500-P.pdf إلى دلو S3 ضمن مجلد اسمه /input. نحن لا نقوم عمدًا بتحميل أحد الموارد المطلوبة.

يجب أن يؤدي هذا إلى إنشاء رسالة مشابهة لما يلي من خلال SNS:

لم نتمكن من معالجة مطالبتك لأننا لم نتمكن من العثور على معلومات التغطية التأمينية الخاصة بك في نظامنا. يرجى الاتصال بمزود التأمين الخاص بك للتحقق من رقم وثيقتك G4683A مع خطة AnyHealth Plus Medicare، أو اتصل بمكتبنا لتحديث معلومات التغطية الخاصة بك.

يحاكي هذا كيفية تعرف الوكيل على المشكلة وإنشاء استجابة صديقة للإنسان لفشل المطالبة.

2. السيناريو الناجح: محاكاة المعالجة الناجحة عن طريق التأكد من وجود موارد HealthLake المطلوبة. في هذا السيناريو، نقوم بإدراج تناقض في البيانات للوكيل لمساعدتنا في التغلب على ذلك. في نموذج البيانات التالي، تم تغيير رقم هوية المؤمن له.

قم بإنشاء المرجع المفقود في HealthLake:

python load_sampledata.py <data_store_id> bda_output_insuredid_error.json Coverage

باستخدام الخطوات السابقة، قم بإعادة معالجة ملف PDF. سوف تتلقى رسالة مثل ما يلي من خلال SNS:

تمت معالجة نموذج المطالبة CMS 1500 بنجاح للمريض John Doe المصاب بآلام الظهر M54.9. تم التعرف على المريض بواسطة DOB (1960/10/10). تم التعرف على الطرف المؤمن عليه Jane Doe من خلال البحث عن الاسم بعد فشل البحث عن الهوية بسبب التناقض بين معرف المطالبة (11-2234-10190) ومعرف قاعدة البيانات (11-2234-1019O) – يختلف الحرف النهائي. تم تحديد الدكتورة جين سميث باعتبارها الطبيبة المُحيلة بواسطة المعرف 123456. وتم التحقق من التغطية بموجب سياسة Medicare G4683A الصادرة عن AnyHealth Plus. تتضمن المطالبة 4 إجراءات: CPT 97810 بتاريخ 2005-10-15 (170 دولارًا)، وCPT 73521 بتاريخ 2005-10-20 (120 دولارًا)، وCPT 98940 بتاريخ 2005-10-30 (250 دولارًا)، وCPT 97124 بتاريخ 2005-10-30 (120 دولارًا)، بإجمالي 660 دولارًا.

يمكن أن تشير هذه الرسالة إلى المراجع البشري بملخص سريع للمطالبة الناجحة وأي ملاحظات أخرى يقدمها الوكيل.

أفضل الممارسات

الذكاء الاصطناعي في وقت التصميم أفضل من الذكاء الاصطناعي في وقت التشغيل. في هذا الحل، منطق التزامن معروف مسبقًا. يمكن التنبؤ بخطوات معالجة المستندات، وتتبع الاستعلامات الأولية لـ HealthLake نمطًا ثابتًا. ونظرًا لأن هذه المتطلبات محددة جيدًا في وقت التصميم، فقد قمنا بتشفير المنطق بشكل صريح بدلاً من الاعتماد على خوادم بروتوكول السياق النموذجي (MCP) لاستنتاج ترتيب العمليات في وقت التشغيل. والنتيجة هي حل أكثر موثوقية وقابلة للصيانة. ولبنائه، استخدمنا Kiro، وهو بيئة تطوير متكاملة تعمل على ترجمة مواصفات اللغة الطبيعية إلى كود عمل. أنشأ Kiro استدعاءات واجهة برمجة التطبيقات (API) إلى Bedrock Data Automation داخل Lambda وقام ببناء الأدوات داخل الوكيل. من خلال إنتاج تعليمات برمجية دقيقة ومستهدفة في وقت التصميم بدلاً من إصدار مطالبات استكشافية واسعة النطاق في وقت التشغيل، قام Kiro بتقليل عدد الاستدعاءات إلى Bedrock. وقد ساعد ذلك على خفض تكاليف التشغيل وتقصير دورة حياة التطوير.

الإشراف الحتمي على الوكلاء. كان استخدام S3 وLambda في هذه البنية مقصودًا. يقوم الوكيل بأمرين أساسيين: مراقبة استدعاءات الأداة الصريحة، وإنشاء مورد FHIR لتحميله في HealthLake. ثم يقوم بعد ذلك بإبلاغ وظيفة Lambda، التي تعمل بمثابة الحكم النهائي لنجاح المطالبة أو فشلها.

تنظيف

يمكن استدعاء الأوامر التالية لإزالة الحل:

cd agentcore
python cleanup_resources.py
npx cdk destroy

التكاليف

القوائم التالية هي اعتبارات التكلفة لكل خدمة مستخدمة.

ملحوظة: تعتمد اعتبارات التكلفة التالية على أسعار AWS اعتبارًا من وقت النشر ويتم توفيرها لأغراض إعلامية فقط. قد تختلف التكاليف الفعلية. للحصول على أحدث الأسعار، راجع صفحات أسعار الخدمات المعنية.

• رسوم AgentCore Runtime تبلغ 0.0895 دولارًا أمريكيًا لكل ساعة وحدة معالجة مركزية افتراضية (vCPU) والذاكرة بسعر 0.00945 دولارًا أمريكيًا لكل جيجابايت/ساعة ستقدم تكلفة اسمية لكل مستند.
• تبلغ تكلفة Amazon Bedrock Data Automation 0.04 USD لكل صفحة للمخططات التي تحتوي على 30 حقلاً أو أقل، و0.0005 USD لكل حقل إضافي يتجاوز 30 حقلاً.
• رسوم النموذج للوكيل باستخدام Anthropic Claude Sonnet 3.7 V1. في مستند الاختبار الخاص بنا، يبلغ عدد الرموز المميزة حوالي 76 ألف مدخل و6 آلاف مخرج. بالنسبة للتسعير عند الطلب، يبلغ هذا المبلغ 0.23 دولارًا أمريكيًا للداخل و0.09 دولارًا أمريكيًا للخارج أو 0.32 دولارًا أمريكيًا للمستند.
• يتم فرض رسوم على AWS HealthLake من خلال سعة التخزين في الساعة، بسعر 0.27 USD في الساعة لأول 10 جيجابايت.
• تعتبر رسوم Lambda وS3 وSNS ضئيلة لكل مستند في هذه البنية.

خاتمة

في حين أن معالجة مطالبات الرعاية الصحية للإنتاج غالبًا ما تتضمن خطوات إضافية تتجاوز هذا الحل، فإن هذا النمط يوضح قوة دمج وكلاء الذكاء الاصطناعي في سير عمل المستندات. من خلال منح وكيل الذكاء الاصطناعي إمكانية الوصول المباشر إلى أدوات المعالجة، يمكنه تقديم رؤى قيمة بطرق متعددة: تحديد مشكلات المطالبات المحتملة، وتسليط الضوء على المجالات التي تحتاج إلى مراجعة بشرية، وإنشاء رسائل حالة ملائمة للمريض. يمكن أن يساعد هذا النهج المدعوم بالذكاء الاصطناعي معالجات المطالبات على العمل بكفاءة أكبر وتقليل أوقات المعالجة مع الحفاظ على الدقة. يعرض المثال السابق سيناريو محتملاً: وجود تناقض في البيانات بين الحروف س والرقم صفر. في هذه الحالة، يتنقل الوكيل في التناقض ويعالج المطالبة بدقة.

لمعرفة المزيد حول إنشاء حلول ذكية لمعالجة المستندات، استكشف وثائق Amazon Bedrock أو راجع حلول الرعاية الصحية الأخرى في AWS Architecture Center.

عن المؤلفين