Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
البنية التحتية للسجل الطبي الرقمي
البنية التحتية التي يحتاجها السجل الطبي الرقمي — الهيكل، التاريخ، المستندات، العزل، الموافقة، التدقيق، التبادل — ولماذا يتم فصله عن التطبيق الموجه للمريض.
يحتاج السجل الطبي الرقمي إلى شيئين مختلفين: تطبيق مواجه للمريض يستخدمه الأشخاص يوميًا، والبنية التحتية التي تخزن السجل وتحميه وتشاركه. توفر Anpheros الجزء الثاني: تخزين السجل، وإدارته بالإصدارات، والهوية، والموافقة، والتدقيق، والتبادل، من خلال واجهة برمجة تطبيقات (API). يمكن أن يكون التطبيق المواجه للمريض هو Anpheros Daily، أو تطبيقًا تقوم ببنائه.
التطبيق مقابل البنية التحتية
| التطبيق المواجه للمريض | البنية التحتية للبيانات الطبية | |
|---|---|---|
| ما هو | شاشات، إشعارات، تذكيرات، رسوم بيانية، مساعد | السجل نفسه والقواعد المحيطة به |
| يتغير غالبًا | نعم — التصميم، الميزات، المنصات | نادرًا — يجب أن يظل مستقرًا ومتوافقًا |
| أمثلة على العمل | مفكرة للأعراض، تذكير بالأدوية، تقويم عائلي | تخزين FHIR، سجل الإصدارات، الموافقة، المصدر، التدقيق، استيراد المختبر، خطافات الويب |
| في Anpheros | Anpheros Daily (Android، macOS، ويب) | Anpheros Platform (platform.anpheros.com) |
إن إبقائهما منفصلين هو ما يسمح للسجل بأن يعيش أطول من أي تطبيق فردي وأن تتم مشاركته بين عدة تطبيقات. يتبع Anpheros Daily هذا التقسيم: ما يسجله الأشخاص في التطبيق يُكتب إلى المنصة عبر نفس واجهة برمجة التطبيقات العامة التي تستخدمها أي تطبيقات أخرى، لذا فهو متاح — بموافقة المريض — للتطبيقات الأخرى بنفس شكل FHIR.
ما يجب أن توفره البنية التحتية
الهيكل
السجل يكون مفيدًا فقط إذا كان بإمكان البرامج الأخرى فهمه. يخزن Anpheros السجلات كموارد HL7 FHIR R4 — 26 نوعًا — مع رموز قياسية (LOINC, ICD-10, ATC, UCUM) ويحتفظ بالنص الأصلي بجوار كل رمز. منصة FHIR
التاريخ
يتم تصحيح البيانات الطبية، ولا يتم الكتابة فوقها. كل تحديث ينشئ إصدارًا جديدًا، يمكن قراءته عبر /fhir/R4/{type}/{id}/_history؛ التحديثات الشرطية باستخدام If-Match تمنع كاتبين من الكتابة فوق بعضهما البعض (الإصدار القديم يستجيب بـ 412).
المستندات
يتم تخزين المسح الضوئي وملفات PDF كـ DocumentReference مع الملف الأصلي: يتم تحميلها عبر المنصة أو مباشرة إلى التخزين، ثم يتم الانتهاء منها باستخدام تدقيق SHA-256 وحجم الملف. بعد الانتهاء، لا يمكن تغيير الملف الأصلي؛ تشير القيم المستخرجة منه إليه (derived_from). يتم الاحتفاظ بالملفات في حاوية تخزين في الاتحاد الأوروبي مشفرة بمفتاح يديره العميل، بحد أقصى 25 ميبي بايت لكل منها.
الهوية والعزل
يعمل كل تطبيق داخل مشروع ويرى فقط مرضاه الخاصين (بالإضافة إلى أولئك الذين منحوه حق الوصول)، تحت معرفاته المزدوجة الخاصة. السجل خارج نطاق وصوله لا وجود له بالنسبة له (404).
الموافقة
يمنح المريض التطبيق حق الوصول لفترة (30-365 يومًا)، لأنواع موارد وإجراءات محددة، ويمكن اختياريًا تقييدها بفئة. يتم عكس الموافقات كموارد FHIR Consent ويمكن إلغاؤها في أي وقت. نموذج الموافقة والوصول
المصدر والتدقيق
يسجل كل كتابة من كتبها (المريض، الممارس، الجهاز، الاستيراد أو الذكاء الاصطناعي)، ولأي منظمة ومن أي نظام. يتم تسجيل كل قراءة وتظهر للمريض حسب التطبيق.
التبادل
يمكن تصدير السجل بالكامل (Patient/$everything)، وتلخيصه بتنسيق الملخص الدولي للمريض (Patient/$summary)، وتغذيته من قبل المختبرات (CSV, HL7 v2 ORU^R01, JSON)، ومراقبته عبر خطافات الويب الموقعة. تكاملات الرعاية الصحية
الإقامة والحذف
يتم تخزين البيانات ومعالجتها في الاتحاد الأوروبي. حذف المريض يحذف كل مورد من موارد السجل.
بناء تطبيقك الخاص للمرضى
إذا كنت تبني طبقة التطبيق، يمكنك التركيز على تجربة المستخدم واستخدام Anpheros للسجل:
- إنشاء مريض لكل مستخدم (
POST /v1/patients) أو طلب موافقة من مستخدم Anpheros حالي؛ - كتابة ما يسجله المستخدم (
/v1/patients/{id}/observations،/conditions،/medications،/documents)؛ - قراءته مرة أخرى كقوائم أو جدول زمني (
/v1/patients/{id}/timeline)؛ - الاشتراك في خطافات الويب (webhooks) لتحديث الشاشات عندما يضيف مختبر أو عيادة شيئًا ما.
الشرح الكامل موجود في Build a healthcare app.
ذات الصلة
- السجل الطبي للمريض
- الواجهة الخلفية وقاعدة بيانات التطبيق الطبي
- الأمان والخصوصية ومكان البيانات
- البنية التحتية للبيانات الطبية
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card