Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
مخطط قاعدة بيانات FHIR
كيفية تخزين موارد FHIR: جداول مُطبعة مقابل JSON مع فهارس بحث مقابل الرسم البياني، مخطط PostgreSQL الذي يعمل عليه Anpheros (الموارد، التاريخ، الفهارس المكتوبة، الإسقاطات) والقواعد المهمة.
تُخزِّن قاعدة بيانات FHIR موارد HL7 FHIR بحيث يمكن قراءتها والبحث فيها وإصدارها عبر واجهة برمجة تطبيقات FHIR؛ يحتفظ المخطط الأكثر شيوعًا بكل مورد كـ JSON ويملأ جداول فهرسة منفصلة لمعلمات البحث، بدلاً من توزيع كل عنصر عبر جداول علائقية مُطَبَّعة. تشرح هذه الصفحة التصميمات الثلاثة الشائعة، والمخطط الذي يعمل به Anpheros في PostgreSQL، ومتى لا يجب عليك بناء واحد بنفسك.
ثلاث طرق لتخزين FHIR
| Normalised tables | JSON + search indexes | Graph database | |
|---|---|---|---|
| Stores any valid resource unchanged | — | ✓ | ✓ |
| Standard FHIR search on any parameter | ◐ | ✓ | ◐ |
| New fields need a schema migration | ✓ | — | — |
| Easy SQL reporting | ✓ | ◐ | — |
| Used by mainstream FHIR servers | ◐ | ✓ | — |
◐ = possible with extra work. HAPI FHIR and Anpheros both keep the resource as JSON and index search parameters separately.
موارد FHIR عميقة، اختيارية وقابلة للتوسيع: يحتوي مورد Observation وحده على عشرات العناصر، وأنواع الاختيار (value[x])، وترميزات متكررة وامتدادات. تطبيع ذلك إلى أعمدة علائقية يعني حدوث ترحيل في كل مرة يضيف فيها ملف تعريف حقلاً. تخزين المورد بصيغة JSON يحافظ على أي شيء صالح دون تغيير؛ جداول الفهرسة تجعله قابلاً للبحث.
مخطط Anpheros
- APIFHIR R4 REST and the simpler /v1 REST API
- Current resourcesOne row per resource: type, id, patient, version, the full FHIR JSON (JSONB)
- Search indexesTyped tables filled on every write: token, string, date, reference, quantity
- HistoryEvery version of every resource, never overwritten
- ProjectionsFlat tables for the common REST views: observations, conditions, medications
- PostgreSQLOne database per environment; sandbox and production are separate
| الجدول | صف واحد لكل | الأعمدة الرئيسية |
|---|---|---|
fhir_resources |
الإصدار الحالي للمورد | resource_type، id، patient_id، version، json (المورد الكامل)، last_updated، deleted، بالإضافة إلى أعمدة المصدر |
fhir_history |
كل إصدار تم كتابته على الإطلاق | resource_type، id، version، json، last_updated |
idx_token |
قيمة البحث المشفرة أو المعرّفة | system، code — لـ code، category، identifier، status |
idx_string |
قيمة البحث النصي | النص المُطبع — للأسماء والنصوص الحرة |
idx_date |
قيمة البحث عن التاريخ | بداية ونهاية النطاق — لـ date، onset-date، birthdate |
idx_reference |
قيمة البحث عن المرجع | نوع الهدف ومعرفه — لـ patient، subject، encounter |
idx_quantity |
قيمة البحث عن الكمية | value، system، unit — لـ value-quantity |
proj_observations، proj_conditions، proj_medications |
المورد، مسطح | الأعمدة التي تقوم واجهة برمجة تطبيقات REST البسيطة بالتصفية عليها |
عند كل عملية كتابة، تقوم المنصة بالتحقق من صحة المورد، وتكتب الإصدار الجديد إلى fhir_resources و fhir_history، وتستبدل صفوف الفهرس والإسقاطات الخاصة بها، وتسجل المصدر (Provenance). يصبح البحث مثل Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01 عمليات ربط (joins) على idx_reference، idx_token و idx_date؛ وتعيد النتيجة تخزين JSON كما تمت كتابته.
قواعد التصميم الهامة
- فهرسة معلمات البحث المعلنة فقط: ورفض المعلمات غير المعروفة باستخدام
400بدلاً من تجاهلها بصمت. - لا تقم بالتحديث في المكان بدون سجل: يجب أن تحتفظ التصحيحات بما كان معروفًا من قبل.
- الحذف الناعم (Soft delete): المورد المحذوف يختفي من عمليات القراءة والبحث، ولكن تبقى إصداراته للمراجعة.
- عمود قسم المريض (Patient compartment column): تخزين
patient_idعلى كل مورد يجعل$everything، وفلاتر الموافقة، والعزل لكل مريض أمرًا سهلاً. - التحقق قبل التخزين: JSON غير صالح في المخزن يكسر كل قارئ لاحقًا.
أسئلة متكررة
ما هي أفضل قاعدة بيانات لـ FHIR؟
تستخدم معظم خوادم FHIR الإنتاجية قاعدة بيانات علائقية مثل PostgreSQL مع تخزين الموارد كسلسلة JSON (JSONB) وفهرسة معلمات البحث في جداول منفصلة. يجمع هذا بين التخزين المرن والبحث القياسي السريع.
هل يجب عليّ تطبيع موارد FHIR إلى جداول علائقية؟
عادةً لا، ليس للتخزين الأساسي. الجداول المطبعة مناسبة للتقارير؛ احتفظ بها كإسقاطات مبنية من الموارد المخزنة، كما تفعل Anpheros لواجهة برمجة تطبيقات REST الأبسط الخاصة بها.
كيف تخزن HAPI FHIR الموارد؟
يخزن خادم JPA الخاص بـ HAPI FHIR أيضًا كل إصدار من المورد كسلسلة JSON مُسلسلة ويحتفظ بمعلمات البحث في جداول فهرسة منفصلة. يتبع تصميم Anpheros نفس المبدأ.
هل أحتاج إلى بناء قاعدة بيانات FHIR بنفسي؟
فقط إذا كنت بحاجة إلى تحكم كامل في الملفات الشخصية وأنواع الموارد. بخلاف ذلك، توفر لك منصة FHIR المُدارة التخزين والبحث والسجل والموافقة والتدقيق دون الحاجة إلى تشغيل المخطط.
ذات الصلة
- FHIR مقابل قاعدة بيانات طبية مخصصة
- كيفية تخزين السجلات الطبية باستخدام FHIR R4
- قاعدة بيانات FHIR مجانية وبيئة اختبار
- كيف تقارن Anpheros بخوادم FHIR الأخرى
- منصة FHIR
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card