العرض الفني
لنظام الملفات الطبية
العرض الفني لنظام الملفات الطبية
الواجهة الخلفية
الواجهة الخلفية هي جزء من النظام الأساسي لبرنامج السجلات الصحية الإلكترونية ، وتتكون من المكونات أساسية لادارة وضبط وحوكمة البرنامج على جميع المستويات من قبل مسؤولي النظام حسب الصلاحيات المحددة لهم
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩
نحن نوفر FHIR API والاشتراكات و GraphQL وواجهة برمجة تطبيقات SQL. ويمكن توسيعها باستخدام عمليات مخصصة.

تدعم هذه الخدمة جميع الإصدارات الرئيسية من FHIR: DSTU2 و STU3 و R4. يضمن التحقق الصارم اتساق البيانات وسلامتها لجميع موارد FHIR. وباستخدام الاشتراكات، يمكن للمستخدمين تنفيذ أطر مخصصة في تطبيقاتهم عندما تتغير بيانات معينة.

واجهة برمجة تطبيقات GraphQL

يدعم النظام تطبيق GraphQL الافتراضي بدون أي ملحقات. يقوم بإنشاء مقاييس مختلفة من GraphQL ، ومكونات ، واستعلامات مع وسائط واتحادات من بيانات تعريف FHIR.
قم بتنزيل PDF
واجهة برمجة التطبيقات التفاعلية والاشتراكات REST API - FHIR & GraphQL
١
٢
٣
٤
٥
٦
٧
٨
٩
واجهة برمجة التطبيقات التفاعلية والاشتراكات REST API - FHIR & GraphQL
خادم المصادقة

"يتم استخدام خادم المصادقة للتحقق من بيانات الاعتماد عندما يحتاج شخص أو خادم آخر إلى إثبات هويتهم لتطبيق ما. يتخذ نظام هوية Auth0 منهجًا حديثًا للهوية ويمكّن المؤسسات من توفير وصول آمن إلى أي تطبيق لأي مستخدم. Auth0 عبارة عن نظام أساسي قابل للتخصيص بدرجة كبيرة وهو بسيط حسب متطلبات فرق التطوير ومرون بقدر ما يحتاجون إليه.

OpenID هو بروتوكول مصادقة قياسي مفتوح ولامركزي تروج له مؤسسة OpenID غير الربحية. يسمح للمستخدمين بالمصادقة من خلال مواقع التشغيل المشتركة (المعروفة باسم الأطراف المعتمدة ، أو RP) باستخدام خدمة موفر الهوية (IDP) لجهة خارجية ، مما يلغي الحاجة إلى مشرفي المواقع لتوفير أنظمة تسجيل الدخول الخاصة بهم ، والسماح للمستخدمين بتسجيل الدخول إلى عدة مواقع ويب غير ذات صلة دون الحاجة إلى الحصول على هوية وكلمة مرور منفصلة لكل منها. ويحتوي النظام على خادم OAuth 2.0 OpenID Connect مدمج ويمكنه العمل كخادم موارد. "
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩
واجهة برمجة التطبيقات التفاعلية والاشتراكات REST API - FHIR & GraphQL
صلاحية الدخول
يوفر نموذجًا مرنًا لتخصيص قواعد تفويض طلبات الدخول. يُسمح للمستخدم بالإعلان عن مجموعة من الفحوصات لجميع الطلبات الواردة. إذا كان الطلب الوارد يفي بهذه الفحوصات ، فسيتم اعتباره مرخصًا ويتم السماح له بالاستمرار. وإلا يتم رفض الطلب ويحصل العميل على شاشة 403 غير مصرح به. يتم التصريح عن هذه الفحوصات مع مورد AccessPolicy.

الوحدة النمطية HL7v2 / X12
تأتي محولات التكامل مع وحدات تكامل HL7 v.2 و X12. ليست كل الأنظمة التي تتفاعل مع تطبيقات الرعاية الصحية الحديثة تتحدث FHIR حتى الآن. يأخذ دعم معايير التشغيل البيني الأخرى الكثير من العبء على عاتق المطورين.

واجهة برمجة التطبيقات FHIR
توفير تبادل البيانات مع أنظمة FHIR الخارجية.
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩
واجهة برمجة التطبيقات التفاعلية والاشتراكات REST API - FHIR & GraphQL
تحميل واجهة برمجة التطبيقات API
توفير تبادل البيانات مع الأنظمة الخارجية (أي تنسيقات مخصصة أخرى).

الموارد المخصصة
المورد له نوع. يتم وصف جميع أنواع الموارد ب "meta-resources" - الكيان والسمة. تحدد الجهة المعنية المورد أو النوع المعقد وتصف مجموعة السمات هيكلها. ليست كل بيانات الرعاية الصحية تناسب نماذج بيانات FHIR. يسمح النظام بإضافة موارد وسمات مخصصة مع تحديث سهل للبيانات الوصفية عبر RESTful API.
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩
واجهة برمجة التطبيقات التفاعلية والاشتراكات REST API - FHIR & GraphQL
موارد FHIR

يخزن النظام موارد FHIR تقريبًا كما هو الحال مع 3 أنواع من التحويلات المتشابهة:
- مراجع
- الاتحاد (أنواع الاختيار)
- ملحقات من الدرجة الأولى
في FHIR ، يتم تمثيل المراجع كسلسلة URI. في معظم الحالات ، أنت مهتم بأجزاء منفصلة من المراجع مثل معرف المورد ونوعه. لأسباب تتعلق بالأداء والدقة ، يوزع النظام المرجع ويخزن أجزائه في مجالات منفصلة.
أنواع الاتحاد (الاختيار): يمكن أن تحتوي بعض العناصر على أنواع متعددة.
ملحقات من الدرجة الأولى - بينما تستخدم FHIR طريقتين مختلفتين لتحديد العناصر الأساسية والامتدادات ، يوفر النظام إطارًا موحدًا لوصف كليهما. وهو يدعم السمات المعرفة من قبل المستخدم أو " ملحقات الدرجة الأولى ". لذلك ، يمكن تحديد سمات (عناصر) جديدة لموارد (FHIR) الحالية.
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩
واجهة برمجة التطبيقات التفاعلية والاشتراكات REST API - FHIR & GraphQL
الاشتراكات
هذه الوحدة هي طريقة للاشتراك والحصول على إشعارات حول تحديث الموارد على الخادم. وهي قاسم مشترك لمواصفات اشتراكات FHIR R4 / R5 مع بعض الامتدادات.

تقدم هذه الوحدة مصدرين جديدين في النظام:
- Subscription - مصدر التعريف الذي يربط الأحداث (إنشاء / تحديث / حذف المورد) بقناة اتصال يتم من خلالها إخطار المشترك بالتغييرات.
- SubsNotification - المورد الذي يمثل الإخطار بحالته (مرسلة أم لا).

SDKs
يتكامل النظام بسرعة وسهولة مع SDK الذي يدعم لغة اختيار فريق التطوير لديك.
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩
واجهة برمجة التطبيقات التفاعلية والاشتراكات REST API - FHIR & GraphQL
مراجعة
يقوم النظام تلقائيًا بتسجيل جميع أحداث المصادقة وواجهة برمجة التطبيقات وقاعدة البيانات والشبكة ، لذلك في معظم الحالات ، قد يتم اشتقاق سجل التدقيق الأساسي من سجلات النظام. قدم معيار FHIR موارد AuditEvent في النظام البيئي FHIR. يوفر النظام FHIR API شامل لمورد AuditEvent.

المصطلح
تأتي مصطلحات النظام مع FHIR و ICD-10 و SNOMED و RxNorm و LOINC و US NPI. يمكن للمستخدمين توسيعها بمصطلحات أخرى ومجموعات قيم مخصصة.
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩
قاعدة البيانات
تستخدم PostgreSQL المتوافقة مع FHIR مع SQL على نظام دعم FHIR PostgreSQL حصريًا ولكنها تستخرج كل شيء من تقنية قاعدة البيانات هذه. تأتي معظم مرونة وأداء النظام من ميزات PostgreSQL المتقدمة مثل JSON الثنائي ، ونظام الفهرسة الغني ، وما إلى ذلك. SQL هي ثاني واجهة برمجة تطبيقات للنظام ، والتي تمنحك قوة إضافية على البيانات المنظمة.
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩
ذكاء الأعمال والأدوات التحليلية
تصدير بيانات النظام إلى Power BI أو أي أدوات تحليلية أخرى
وأنظمة ذكاء الأعمال الأخرى
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩
خط أنابيب التكامل في الوقت الحقيقي
التصدير أثناء استيراد البيانات من مستندات CCDA ، هناك العديد من الفروق الدقيقة في كل خطوة. كيف يتلقى نظامك مستندات CCDA؟ ما هي عناصر البيانات التي تريد استمرارها؟ كيف يمكن لنظامك إلغاء تكرار سجلات المرضى؟

نظرًا لأن الإجابات على هذه الأسئلة خاصة بالنظام تمامًا ، لا يوفر النظام حلاً جاهزًا للاستخدام هنا. ولكن يمكننا تنفيذ نظام جديد ، باستخدام أي مجموعة تقنية مفضلة .
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩
استقبال ملفات CCDA
تتمثل الخطوة الأولى في فهم كيفية تلقي النظام لملفات CCDA. في حالة وجود تطبيق يواجه المستخدم مثل Patient Portal أو EHR ، سيقوم مستخدم EHR بتحميل ملف CCDA الخا به يدويًا. الحالة الشائعة الأخرى هي الاستيراد المجمع من التخزين البعيد مثل خادم SFTP أو دلو S3.

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

هناك العشرات من الطرق لإعداد مثل هذه القائمة ، ربما تكون أبسطها هي استخدام مورد DocumentReference (إذا عرفنا مريضًا ينتمي إليه هذا المستند). بدلاً من ذلك ، يمكننا استخدام خدمة قائمة انتظار مخصصة مثل Apache Kafka أو مجرد جدول مخصص في RDBMS. ومع ذلك ، على الرغم من التخزين الذي سنستخدمه ، فإننا سنخزن ملف CCDA الأصلي حتى نتمكن من الوصول إليه في أي وقت.

في الخطوة التالية ، سيقوم نوع من العمل في الخلفية أو عامل باختيار الملفات المستلمة من قائمة الانتظار ومعالجتها واحدة تلو الأخرى .
قم بتنزيل PDF
١
٢
٣
٤
٥
٦
٧
٨
٩