AnpherosAnpheros PlatformDevelopers

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()
);

بسيطة وسريعة الاستعلام، بالضبط ما يحتاجه التطبيق. ثم تأتي الأسئلة التي لا تجيب عليها الجدول:

نفس القراءة بصيغة 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 هو الخيار الصحيح

المسار الأوسط المعتاد

ينتهي الأمر بمعظم المنتجات بكليهما، مقسمة حسب نوع البيانات:

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 يسهل الوفاء بالعديد من الالتزامات: قابلية النقل (يتم تصدير السجل بتنسيق قياسي)، التحكم في الوصول حسب الغرض، وإظهار من قام بمعالجة أي بيانات.

ذات الصلة

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Product updates by email

New features, guides and the end of the beta. One email a month at most.

Send me occasional Anpheros Platform updates by email (new features, API changes, guides). I'll confirm by email and can unsubscribe in one click from any email. Privacy