Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
FHIR مقابل قاعدة بيانات طبية مخصصة
جداولك الخاصة أو HL7 FHIR R4 للبيانات الطبية: نفس القراءة المخزنة بالطريقتين، المقايضات جنبًا إلى جنب، متى يكون كل منهما مناسبًا، والتقسيم المعتاد بين قاعدة بياناتك والسجل FHIR.
يواجه الفريق الذي يبدأ منتجًا صحيًا عادةً نفس الاختيار مبكرًا: تصميم جداوله الخاصة للمرضى والقياسات والتشخيصات في PostgreSQL أو قاعدة بيانات أخرى، أو تخزين البيانات الطبية كموارد HL7 FHIR R4 من البداية. المخطط المخصص أسرع في اليوم الأول ويتناسب تمامًا مع منتجك. يكلف FHIR المزيد من التفكير مقدمًا ويدفع ثمنه في كل مرة يجب فيها مغادرة البيانات لنظامك، أو تدقيقها، أو مشاركتها بموافقة، أو قراءتها بواسطة شخص غيرك. تحدد هذه الصفحة المقايضات بصدق، مع تخزين نفس القراءة بالطريقتين، وتقول متى يكون كل خيار مناسبًا.
هذا سؤال مختلف عن أي خادم FHIR يجب استخدامه. لهذا، راجع كيف تقارن Anpheros بخوادم FHIR الأخرى.
نفس القراءة، بطريقتين
قراءة ضغط الدم في مخطط مخصص:
CREATE TABLE bp_readings (
id uuid PRIMARY KEY,
user_id uuid REFERENCES users(id),
systolic int,
diastolic int,
measured_at timestamptz,
created_at timestamptz DEFAULT now()
);
بسيطة وسريعة الاستعلام، بالضبط ما يحتاجه التطبيق. ثم تأتي الأسئلة التي لا تجيب عليها الجدول:
- ما هو الجهاز أو الشخص الذي أنتج القيمة؟ هل قام المريض بكتابتها، أم تم قياسها بجهاز قياس، أم أدخلتها ممرضة؟
- ما هي القيمة قبل أن يقوم شخص ما بتصحيحها، ومن قام بتصحيحها؟
- كيف تقرأها أنظمة العيادات، أو المختبرات، أو شركات التأمين؟ ماذا يعني
systolicفي نظامهم؟ - كيف يشاركها المريض مع تطبيق طبيبه ويتوقف عن مشاركتها الشهر المقبل؟
- عند إضافة معدل ضربات القلب، والوزن، و HbA1c و 200 قياس آخر، هل هذه 200 جدول أم جدول واحد عام تصممه بنفسك؟
نفس القراءة بصيغة FHIR R4:
{"resourceType": "Observation", "status": "final",
"category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
"code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
"subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
"component": [
{"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
{"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
"meta": {"versionId": "1"}}
أكثر تفصيلاً، ولكن كل جزء له معنى تشاركه أي نظام FHIR: LOINC يحدد ما تم قياسه، UCUM يحدد الوحدة، meta.versionId يبدأ التاريخ، ونفس شكل Observation يحمل القياسات الـ 200 الأخرى. مع Anpheros، يسجل مورد Provenance أيضًا من قام بكتابته. كيفية تخزين السجلات الطبية باستخدام FHIR R4 يشرح ذلك بالتفصيل.
جنبًا إلى جنب
| مخطط مخصص | FHIR R4 | |
|---|---|---|
| الوقت حتى الميزة الأولى | ساعات | يوم أو يومان لتعلم الموارد |
| الملاءمة لمنتجك | دقيق | عام؛ عرض منتجك يقع فوقه |
| إضافة نوع جديد من البيانات | ترحيل لكل نوع | عادةً رمز جديد في مورد موجود |
| المعنى خارج نظامك | لا شيء بدون تعيين | رموز مشتركة (LOINC, ICD-10, ATC, UCUM) |
| السجل والتصحيحات | أنت تصممها | إصدارات و _history حسب التصميم |
| من كتب ماذا | أنت تصممها | Provenance (تلقائي في Anpheros) |
| التبادل مع العيادات والمختبرات والتطبيقات الأخرى | تكامل مخصص في كل مرة | واجهة برمجة تطبيقات FHIR R4، استيراد HL7 v2، ملخص المريض الدولي |
| موافقة المريض لكل تطبيق | أنت تصممها | نطاقات SMART on FHIR و OAuth |
| الاستعلام عن التحليلات | SQL عادي | بحث FHIR، أو تصدير إلى مستودع البيانات الخاص بك |
| اللوائح (المادة 9 من اللائحة العامة لحماية البيانات، EHDS) | أنت توثق كل جزء | تنسيقات قياسية تشير إليها اللائحة |
متى يكون المخطط المخصص هو الخيار الصحيح
- البيانات ليست طبية حقًا، أو ليست عن شخص واحد. خطط التدريب، المحتوى، كتالوج المنتجات: استخدم جداولك الخاصة.
- نموذج أولي قصير الأجل لاختبار ما إذا كان أي شخص يريد المنتج، مع بيانات اصطناعية وخطة للانتقال.
- البيانات لا تتناسب مع النماذج القياسية بشكل جيد، على سبيل المثال قياس بحثي جديد. لا يزال بإمكان FHIR حمله (
Observationمع نظام الرموز الخاص بك، أوBasic)، ولكن قد يكون الجدول المخصص أوضح. - تحليلات مكثفة. حتى مع استخدام FHIR كنظام للسجلات، تقوم معظم الفرق بنسخ البيانات إلى مستودع بيانات بتنسيقها الخاص لإعداد التقارير.
متى يكون FHIR هو الخيار الصحيح
- البيانات هي السجل الصحي للشخص: القياسات، التشخيصات، الأدوية، الحساسية، نتائج المختبر، المستندات.
- ستغادر بياناتك نظامك في وقت ما: إلى المريض، طبيب، عيادة، مختبر، شركة تأمين، نموذج ذكاء اصطناعي، أو منافس عندما ينتقل المريض.
- تحتاج إلى إظهار من كتب ماذا وما الذي تغير: عمليات التدقيق، السلامة السريرية، النزاعات.
- سيمنح المرضى الإذن ويلغونه لكل تطبيق.
- تبيع في الاتحاد الأوروبي، حيث يتوقع مساحة بيانات الصحة الأوروبية (EHDS) أن تكون السجلات قابلة للتبادل بتنسيقات قياسية.
المسار الأوسط المعتاد
ينتهي الأمر بمعظم المنتجات بكليهما، مقسمة حسب نوع البيانات:
your database FHIR record (Anpheros)
───────────── ──────────────────────
users, sessions, settings Patient
subscriptions, billing Observation, Condition, MedicationStatement
product content, feature flags AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column) Provenance, Consent, history
caches and analytics copies ◄─────── webhooks
تبقى قاعدة بياناتك صغيرة وشكلها مناسب للمنتج. السجل الطبي قياسي، ومُدار الإصدارات، وقابل للمشاركة، ولم تضطر إلى بنائه. يصف الواجهة الخلفية وقاعدة بيانات التطبيق الطبي هذا التقسيم بالتفصيل، ويقوم كيفية بناء واجهة برمجة تطبيقات الرعاية الصحية باستخدام TypeScript ببنائه.
ما يلزم لبناء FHIR بنفسك
اختيار FHIR لا يعني كتابة خادم FHIR. خياراتك هي خادم مفتوح المصدر تقوم بتشغيله، أو مخزن FHIR لمزود سحابي، أو منصة رعاية صحية مفتوحة المصدر، أو قاعدة بيانات رعاية صحية مُدارة مثل Anpheros. تختلف هذه الخيارات فيمن يتعامل مع الموافقة، والتدقيق، والمصدر، والإقامة، والتكاملات، وهو ما يوضحه كيف تقارن Anpheros بخوادم FHIR الأخرى.
أسئلة متكررة
هل FHIR قاعدة بيانات؟
لا. FHIR هو معيار لهيكلة وتبادل البيانات الصحية: الموارد، والرموز، وواجهة برمجة تطبيقات REST. يقوم خادم FHIR أو قاعدة بيانات FHIR المُدارة بتخزين الموارد وتنفيذ واجهة برمجة التطبيقات فوق قاعدة بيانات حقيقية.
هل يمكنني تخزين موارد FHIR في PostgreSQL بنفسي؟
نعم، كأعمدة JSON مع فهارسك الخاصة، وبعض الخوادم مفتوحة المصدر تفعل ذلك بالضبط. العمل يكمن في كل ما يتعلق بالتخزين: معلمات البحث، الإصدار، المراجع، التحقق من الصحة، التحكم في الوصول لكل مريض، والأصل.
هل يمكنني البدء بمخطط مخصص والانتقال إلى FHIR لاحقًا؟
يمكنك ذلك، والعديد من الفرق تفعل ذلك، لكن الترحيل هو مشروع تعيين: كل جدول يحتاج إلى رموز ووحدات ومؤلفين لم يسجلها من قبل. تخزين البيانات الطبية بصيغة FHIR من الميزة الأولى يكلف أقل من تحويلها لاحقًا.
هل أحتاج إلى FHIR للامتثال للائحة العامة لحماية البيانات (GDPR)؟
لا. لا تتطلب اللائحة العامة لحماية البيانات تنسيقًا معينًا. FHIR يسهل الوفاء بالعديد من الالتزامات: قابلية النقل (يتم تصدير السجل بتنسيق قياسي)، التحكم في الوصول حسب الغرض، وإظهار من قام بمعالجة أي بيانات.
ذات الصلة
- مخطط قاعدة بيانات FHIR: كيفية تخزين موارد FHIR وفهرستها
- كيفية تخزين السجلات الطبية باستخدام FHIR R4
- منصة FHIR
- كيف تقارن Anpheros بخوادم FHIR الأخرى
- الواجهة الخلفية لقاعدة بيانات التطبيقات الطبية
- واجهة برمجة تطبيقات الرعاية الصحية
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card