الحل الظاهري للرعاية الصحية علي Microsoft Cloud for Healthcare

Azure

تتناول هذه المقالة حلاً محتملاً لجدولة ومتابعة الزيارات الافتراضية بين المرضى وموفري الخدمات ومديري الرعاية.

بناء الأنظمة

بنية للزيارة الظاهرية باستخدام Microsoft Cloud للرعاية الصحية

قم بتنزيل ملف Visio يحتوي على هذا الرسم التخطيطي للبنية.

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

تتدفق البيانات إلى النظام من خلال أنظمة طبية خارجية مختلفة، مثل جداول المرضى وموفري الخدمات، والسجلات الطبية، والأجهزة القابلة للارتداء، وما إلى ذلك. تتم استضافة هذه البيانات باستخدام Azure. ثم يتم تخزينها في Microsoft Dataverse، وهو مخزن بيانات مدعوم في النظام الأساسي Power Apps. يتم تنسيق هذه البيانات لاستخدام الكيانات والعلاقات بينها، والتي تم إنشاؤها باستخدام نموذج البيانات العامة (CDM)، وهو معيار صناعي لتمثيل البيانات الطبية. تحدث جميع التفاعلات بين المريض وموفر الخدمة ومدير الرعاية باستخدام بيانات CDM المخزنة في Dataverse.

يمكن للمريض المستقر تسجيل الدخول بأمان إلى مدخل المريض، وهو موقع ويب مستضاف في Power Apps Portals. في هذا المدخل، يمكن للمريض التحدث إلى Intelligent Assistant. هذا هو مثيل لخدمة Azure Health Bot، التي تجمع أعراضها، وتقدم اقتراحات، وتوصي بالاتصال بالطبيب، إذا لزم الأمر. إذا اختار المريض الاتصال بموفر الخدمة الطبية الخاص به، فإن مثيل روبوت الصحة يحصل على البيانات حول الموفرين المتاحين للزيارات الظاهرية وجداولهم الزمنية، من Dataverse. بمجرد أن يختار المريض موفرا ووقتا، يقدم الروبوت معلومات الاتصال الخاصة به، التي تم الحصول عليها من بيانات EMR/EHR المخزنة في Dataverse. يمكن للمريض التحقق من صحة هذه المعلومات أو تغييرها، وحفظ البيانات باستخدام الروبوت.

لجدولة موعد، يتصل مثيل روبوت الرعاية الصحية بتطبيق Bookings باستخدام Microsoft Graph API ويحجز موعداً في تقويم موفر الخدمة. يتم إرسال رسالة بريد إلكتروني تتضمن معلومات الموعد إلى كلا الطرفين باستخدام Microsoft Outlook. يتم إعطاء المريض تعليمات لتسجيل الدخول إلى مدخل المريض بشأن عملية تناول الجرعات. تتضمن هذه العملية تأكيد أو تغيير معلومات الاتصال والدفع والتأمين الخاصة بهم، ثم توقيع نموذج الموافقة للزيارة الافتراضية. بمجرد توقيعهم على الموافقة، يتم تزويدهم برابط Microsoft Teams حول الموعد.

يسجل الموفر الدخول إلى Teams للتحقق من جدول المواعيد والمعلومات الموجزة لكل منها. يعرض Teams هذه المعلومات باستخدام تطبيق Appointment Queue. ثم يتمكن الموفر من بدء الزيارة الظاهرية في Teams للموعد المجدول. أثناء المكالمة، يمكن للموفر تدوين الملاحظات وإضافتها إلى سجلات المريض.

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

المكونات

تتكون البنية من المكونات التالية:

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

  • EMR/EHR. توفر السجلات الطبية الإلكترونية (EMR) والسجلات الصحية الإلكترونية (EHRs) السجلات الرقمية للمعلومات الطبية والصحية للمريض، بما في ذلك التشخيصات والأدوية والتحصين وما إلى ذلك. يمكن تحديد نطاقها إلى مكتب ممارسة واحد، مثل EMRs، أو مصممة لنطاق أكبر بكثير، والسفر مع المرضى إلى أي مرفق يذهبون إليه، مثل EHRs. هذه مصادر بيانات خارجية مهمة في هذا الحل، وقد تكون تنسيقا غير قياسي غير منظم. على هذا النحو، يجب تحويل هذه البيانات إلى تنسيق يمكن استخدامه من قبل المكونات في هذا الحل.

  • Azure API for FHIR. Azure هي الخطوة الأولى في عملية جلب البيانات إلى النظام البنائي في Microsoft وMicrosoft Cloud للرعاية الصحية. توفر هذه الطبقة واجهة آمنة بين البيانات الخارجية والمكونات الداخلية لهذه البنية. تعمل Azure API بالنسبة للموارد التبادلية للرعاية الصحية السريعة على استضافة البيانات الواردة من مصادر متباينة مثل EMR وPAS والأجهزة، سواء كانت منظمة أو غير منظمة، وتحولها إلى موارد تبادلية للرعاية الصحية السريعة وتظل في Azure. يمكن بعد ذلك استخدام هذه البيانات عبر Microsoft Cloud for Healthcare لدعم الخدمات المختلفة. تم إنشاء Azure API بالنسبة للموارد التبادلية للرعاية الصحية السريعة مع وضع الأمان والتوافق في الاعتبار ومصممة لبيانات PHI (معلومات الرعاية الصحية المحمية). لمزيد من المعلومات حول هذه الطبقة، راجع Azure للرعاية الصحية Azure API للموارد التبادلية للرعاية الصحية السريعة

  • نموذج البيانات العامة. مع نموذج البيانات المشتركة، توفر Microsoft نظام تعريف بيانات تعريف موحد قابل للتوسعة وقابل للتخصيص لاحتياجات تجارية محددة. تتوفر كيانات CDM لأمور مثل CRM والرعاية الصحية والموظفين وما إلى ذلك. لمزيد من التفاصيل، اقرأ معلومات استخدام نموذج البيانات العامة. بالإضافة إلى هذه الكيانات، يمكن للعملاء سحب بيانات الملكية عن طريق تحديد جدول الكيان هذا والحقول الأساسية في نموذج البيانات المشترك، والتي يمكن استخدامها بعد ذلك بسلاسة مع الكيانات الأخرى خلال الحل الخاص بهم.

  • Microsoft Dataverse. Dataverse، قاعدة بيانات ارتباطية تعمل على دعم Microsoft Dynamics 365، هي مستودع البيانات الممثلة في نموذج البيانات العامة. تحتوي على قواعد بيانات لمعلومات المرضى، تتضمن تفاصيل حول أسمائهم ومعلومات العائلة والحالات الطبية وتاريخ الأدوية وما إلى ذلك. كما أنه يحتفظ بالمعلومات التي تم الحصول عليها من أي أجهزة قابلة للارتداء يستخدمها ويسجلها المرضى، بالإضافة إلى جدولة وإدارة البيانات من مؤسسة الرعاية الصحية. يتم تعريف هذه البيانات باستخدام نموذج البيانات العامة.

  • مدخل المريض. يتيح مدخل Power Apps هذا للمرضى عرض سجلاتهم الطبية وحجز المواعيد والدردشة مع مثيل روبوت الصحة وما إلى ذلك. يمكن توسيع هذا المدخل لدعم البيانات الأخرى. هذا المدخل هو جزء من Microsoft Cloud for Healthcare، ويسمح لك بسهولة تدوير المدخل، والذي يمكنه الاتصال بالكيانات في Dataverse، وسحب البيانات مثل معلومات المرضى وخطط الرعاية والمواعيد وما إلى ذلك.

  • Intelligent Assistance. هذا هو مثيل لخدمة Azure Health Bot، التي يمكن للمرضى الوصول إليها من خلال مدخل المرضى. يتم تحميل مثيل روبوت الحماية هذا داخل موقع ويب Azure App Service. وهي قابلة للتخصيص، ويمكن برمجتها باستخدام السيناريوهات المطلوبة من قبل العملاء.

  • تطبيق Bookings. تطبيق Bookings هي خدمة Microsoft 365، مضمنة في Microsoft Cloud for Healthcare. فهو يسهل جدولة أحداث التقويم ويسمح بإنشاء اجتماعات Teams.

  • Microsoft Outlook. يستخدم هذا الحل Microsoft Outlook كجهة عميل للبريد الإلكتروني. يتم دمج تطبيق Bookings الذي يرسل إعلام البريد الإلكتروني مع Outlook. بدلاً من ذلك، يمكن استخدام عميل البريد الإلكتروني المفضل لموفر الرعاية الصحية.

  • Microsoft Teams. Microsoft Teams هو أحد مكونات Microsoft Cloud للرعاية الصحية، ويوفر الواجهة الأمامية للتفاعلات بين المرضى وموفري الخدمات ومديري الرعاية. يمكن للمستخدمين استخدام إصدار مثبت محليا أو إصدار ويب. لمزيد من المعلومات حول Teams، اقرأ وثائق Microsoft Teams.

  • قائمة انتظار المواعيد. تنشئ هذه الأداة صفحة HTML مع البيانات التي تم سحبها من Dataverse، باستخدام Dynamics 365 Web API. تقدم للموفر معلومات حول المواعيد المجدولة لليوم وملخصًا عن كل منها. كما يوفر رابطا للوصول إلى معلومات المريض من خلال تطبيق إدارة الرعاية. تم تطوير قائمة انتظار المواعيد لدعم هذا السيناريو، وليست جزءا من Microsoft Cloud للرعاية الصحية. مصادر البيانات لهذه الأداة هي أساسا أنظمة PAS وسجلات EMR/EHR. إذا كانت هذه الأنظمة تحتوي على أدوات متكاملة لتقديم هذه البيانات، فقد تكون هذه الأدوات بديلا لهذا المكون في عملية نشر فعلية.

  • إدارة الرعاية. أداة إدارة الرعاية هي أحد مكونات Microsoft Cloud للرعاية الصحية. إنه تطبيق Power Apps تم نشره من خلال Dynamics 365. يسحب بيانات المريض EMR/EHR المخزنة في Dataverse بتنسيق CDM، ويقدم طريقة عرض مجمعة في Teams. قد يختار حل مركز الرعاية استخدام نظامه الخاص لوظائفه، وفقًا للطريقة التي يريد بها تقديم هذه المعلومات.

  • Power BI Analytics. هذه أداة تحليل تم إنشاؤها لهذا السيناريو، وهي غير متوفرة مع Microsoft Cloud للرعاية الصحية. في هذا الحل، فإنه يولد معلومات مشتقة من أجهزة IoMT الخاصة بالمريض. قد تكون هذه بيانات مثل معدل ضربات القلب ومستوى الأكسجين في الدم وما إلى ذلك. يستخدم تطبيق إدارة الرعاية هذه البيانات لتقديم رؤى إضافية لمقدمي الخدمات الطبية حول مرضاهم استنادا إلى أنشطتهم اليومية.

  • الأجهزة المتصلة. هذه هي أجهزة إنترنت الأشياء الطبية (IoMT)، وهي أجهزة ذكية للاستخدام الطبي أو الرعاية الصحية. تتضمن أمثلة أجهزة IoMT الأدوات القابلة للارتداء مثل Apple Watch أو Fitbit وأجهزة العرض الطبية أو الحيوية وما إلى ذلك. يمكن للمرضى توفير أجهزتهم من خلال Azure، واختيار السماح لنظام إدارة الرعاية الصحية الخاص بهم بجمع بيانات IoMT هذه لاستخدامها من قبل موفري الخدمة. يمكن للموفرين الحصول على رؤى إضافية من مثل هذه الأجهزة، في الوقت الفعلي تقريبا، وربط الحالات الشاذة مثل معدل ضربات القلب المرتفع لفترة من الوقت، مع الأعراض الحالية للمريض.

  • التشغيل التلقائي مع Power Automate. هذه أداة مخصصة تم إنشاؤها لدعم هذا السيناريو، وهي غير متوفرة مع Microsoft Cloud for Healthcare. نظرًا لأن هذا سيناريو زيارة افتراضي، فقد يكون موفر الخدمة مجرد طبيب تحت الطلب وليس الطبيب المعتاد للمريض. تسمح هذه الأداة لملاحظات الموفر بتشغيل إعلام Teams إلى مدير الرعاية. مدير الرعاية هو عضو في الفريق الطبي الذي يعمل كحلقة وصل بين طبيب الرعاية الأولية (PCP) والمريض، ويعتني بإدارة الرعاية على المدى الطويل. ويمكن الإعلام المرسل إلى مدير الرعاية، الذي يشير إلى ملاحظات جديدة تمت إضافتها للمريض، من مراجعة إدارة رعاية المريض وإجراء التغييرات المناسبة عليها بعد الزيارة.

البدائل

تشكل Azure لخدمات الرعاية الصحية مثل Azure API ل FHIR وAzure Health Bot وواجهة Common Data Model وMicrosoft Dataverse Microsoft Teams المكونات الأساسية لهذا الحل. يمكن استبدال معظم المكونات الأخرى لهذا النظام بالأنظمة المستخدمة حاليا من قبل مرفق الرعاية الصحية:

  • إذا كان نظام EMR/EHR يتضمن مضمنات للحجز والجدولة وإدارة الرعاية، يمكن استخدام هذه المضمنات بدلا من المكونات المقابلة في هذا الحل.

  • يمكن تبديل Bookings وجدولة Outlook وإخطار البريد الإلكتروني بواسطة الأنظمة المستخدمة من قبل مرفق الرعاية الصحية. يمكن القيام بذلك عبر نظام EHR، أو باستخدام تطبيق جهة خارجية. يجب أن يوفر التطبيق واجهة برمجة تطبيقات يمكن لمثيل روبوت الصحة استخدامها لإنشاء المواعيد وجدولتها، بالإضافة إلى القدرة على إنشاء اجتماعات ظاهرية.

  • إذا كان لدى الموفر مدخل مريض تم تنفيذه من خلال نظام EMR/EHR الخاص به، فقد يتم استخدامه بدلا من مدخل المريض. من السهل دمج مثل هذا المكون الخارجي مع هذا الحل، حيث استخدمت هذه المكونات واجهات قياسية، على سبيل المثال، واجهة iFrame للاتصال بمثيل روبوت الحماية. يمكن إنشاء المكونات التي تدعم هذا التدفق على المدخل الخاص، مثل نموذج الموافقة الذي يحتاج المريض إلى توقيعه قبل الانضمام إلى اجتماع Teams.

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

تفاصيل السيناريو

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

أساس هذا الحل هو Microsoft Cloud for Healthcare. يجمع Microsoft Cloud for Healthcare قدرات موثوق بها من Microsoft 365 وAzure وDynamics 365 وPower Platform والنظام البيئي الشريك الشامل لشركة Microsoft لمساعدة مؤسسات الرعاية الصحية في إنشاء حلول رعاية صحية سريعة وفعالة وآمنة.

حالات الاستخدام المحتملة

يستهدف هذا الحل توفير رعاية افتراضية للمرضى في ظل الجائحة الحالية. ومع ذلك، يمكن لمقدمي الرعاية الصحية تطبيقها بسهولة على السيناريوهات التالية:

  • جدولة المتابعة الافتراضية للزيارات الشخصية.

  • تقديم إرشادات طبية في الحالات غير طارئة للمرضى أثناء السفر.

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

الأمان

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

نظراً لأن النظام مبني على بيانات المرضى، يجب تطبيق الاعتبارات الأمنية الأساسية للمعلومات الخاصة عند تطوير هذا الحل:

  • يجب أن تتدفق البيانات المطلوبة فقط عبر النظام في أي وقت. على سبيل المثال، اسحب فقط تلك البيانات من أنظمة EMR/EHR المطلوبة للظهير لجدولة الزيارة الظاهرية وإدارتها. راجع قواعد توافق HIPAA المعمول بها للحصول على إرشادات حول مكان تخزين بيانات المريض، وما يمكن القيام به معها، ومن يجب أن يكون لديه حق الوصول إليها. كن على دراية بأهمية الامتثال في الرعاية الصحية أثناء تطوير الحل الخاص بك. لمزيد من الإرشادات، اقرأ التوافق في Microsoft Cloud for Healthcare.

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

  • الوحدات النمطية التي تتفاعل مع المرضى، مثل تطبيق المساعدة الذكية Bookings، تأخذ بيانات المريض وتخزنها وتستخدمها. يضمن التحكم الصحيح في الوصول والمصادقة في هذه الوحدات النمطية معالجة مخاوف الخصوصية.

نظرا لطبيعة البيانات الخاصة المعنية، يشكل الأمانوالتوافق المبادئ الأساسية في Microsoft Cloud for Healthcare.

يعتمد هذا المثال أيضاً على قواعد الأمان التي تم تعيينها بواسطة Dynamics 365 Teams:

توفر الخدمات الفردية المضمنة في Microsoft Cloud for Healthcare طبقة خاصة بها من الأمان والتوافق:

بالنسبة لعناصر تحكم الأمان المخصصة، ضع في اعتبارك استخدام معرف Microsoft Entra والتحكم في الوصول المستند إلى الدور.

وأخيرًا، عند تنفيذ هذا الحل، ضع في اعتبارك أفضل الممارسات والإرشادات لتطوير حلول Azure الآمنة.

تحسين التكلفة

يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.

للحصول على معلومات تسعير مفصلة حول Microsoft Cloud for Healthcare، راجع كيفية شراء Microsoft Cloud for Healthcare. المكونات التي تشكل Microsoft Cloud للرعاية الصحية، لها متطلبات الترخيص الخاصة بها، مثل:

لإعادة إنشاء مكونات في هذه البنية التي تم تصميمها خصيصًا، ضع في اعتبارك معلومات التسعير للخدمات الأساسية التي تختار استخدامها.

نشر هذا السيناريو

يجب نشر الحل على مراحل:

  1. يجب تثبيت بعض المنتجات/الخدمات كمتطلبات أساسية ل Microsoft Cloud for Healthcare. راجع القائمة التفصيلية في هذه المقالة حول متطلبات الترخيص.

  2. يمكن نشر Microsoft Cloud for Healthcare باستخدام الإرشادات المتوفرة في نشر حلول Microsoft Cloud for Healthcare التي يتم تشغيلها بواسطة Dynamics 365.

  3. يوفر Microsoft Cloud for Healthcare مكونات أساسية لبدء إنشاء حل صحي ظاهري، مثل مدخل المريض Teams Bookings وما إلى ذلك. يجب تخصيص البيانات التي سيتم استخدامها لتشغيل كتل الإنشاء هذه وفقا لاحتياجات العمل.

  4. يجب تخصيص المكونات المتوفرة في Microsoft Cloud for Healthcare ومتطلباتها الأساسية لدعم احتياجات الأعمال:

    1. يجب إنشاء تدفقات Power Automate لدعم إعلامات مدير الرعاية.

    2. يجب تكوين مدخل المريض. قد تحتاج إلى إنشاء نماذج إضافية لعناصر مثل نماذج تسجيل الدخول/الموافقة. اقرأ إعداد مدخل وصول المريض وتكوينه للحصول على مزيد من المعلومات.

    3. يجب توصيل خدمة Azure Health Bot بقاعدة بيانات Dataverse، وتخصيصها لاتصالها مع المرضى. اقرأ تكوين الدردشات التلقائية باستخدام Microsoft Health Bot لمزيد من المعلومات.

    4. راجع تكوين المزامنة مع البيانات السريرية باستخدام Azure FHIR Sync Agentوتضمين تقارير Power BI للتحليات لفهم بعض التكوينات الأخرى التي قد تكون مطلوبة.

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

    1. قائمة انتظار المواعيد

    2. الإعلامات التلقائية باستخدام Power Automate

    3. تطبيق إعداد التقارير باستخدام Power BI

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الخطوات التالية