إجابة مختصرة: CDA يمنحك مستندًا واحدًا: ملف XML موقع حول مريض واحد في لحظة واحدة، مع نص يمكن للإنسان قراءته ومدخلات يمكن للكمبيوتر قراءتها، والتي يجب أن تظل كاملة وغير متغيرة. FHIR يمنحك موارد: مريض، أربعون ملاحظة، ثلاث حالات، كل منها بعنوان URL خاص بها، يتم جلبها والبحث فيها وتحديثها بشكل مستقل عبر واجهة برمجة تطبيقات REST. يمكن لـ FHIR أيضًا تجميع الموارد في مستند (حزمة من نوع document بقيادة Composition)، وهو ما يعادل CDA مباشرة. اختر CDA حيث تتطلب اللائحة أو الشريك ذلك؛ اختر FHIR لواجهات برمجة التطبيقات والتطبيقات وأي شيء يجب الاستعلام عنه بدلاً من قراءته.
الشكلان
يحتوي كل من CDA و FHIR على شكلين مختلفين. يقوم CDA بتبادل مستندات XML كاملة مبنية على أنواع بيانات HL7 v3، ويتم تحديدها بواسطة OIDs، مع سرد إلزامي، وعدم وجود استعلام، وعدم وجود تحديث، وتوقيع المستند بالكامل. يقوم FHIR بتبادل موارد JSON أو XML فردية أو حزم (Bundles)، ويتم تحديدها بواسطة عناوين URL قياسية، مع استعلامات REST مدمجة، وتحديثات ذات إصدارات، وملفات تعريف منشورة في أدلة التنفيذ.
| CDA / C-CDA | FHIR | |
|---|---|---|
| وحدة التبادل | مستند كامل | مورد، أو حزمة من الموارد |
| التنسيق | XML، أنواع بيانات HL7 v3 | JSON أو XML، أنواع بيانات FHIR |
| التحديد | OIDs للقوالب وأنظمة الترميز | عناوين URL (قياسية) للملفات الشخصية وأنظمة الترميز |
| الجزء المقروء بشريًا | <text> إلزامي في كل قسم |
سرد text.div اختياري لكل مورد؛ إلزامي في المستندات |
| النقل | غير محدد؛ يتم نقله بواسطة XDS، Direct، MLLP، البريد الإلكتروني | REST عبر HTTPS محددة بواسطة المعيار؛ أيضًا المراسلة والمستندات |
| الاستعلام | غير ممكن داخل مستند؛ تسجل السجلات الرأس | مدمج: GET /Observation?patient=…&code=… |
| التحديث | لا أبدًا؛ مستند جديد يحل محل القديم | يتم إصدار الموارد وتحديثها في مكانها |
| التوقيع | مستند كامل، XML-DSig | حزمة كاملة ممكنة؛ نادرًا ما يتم توقيع الموارد الفردية |
| الملفات الشخصية | قوالب (templateId) لكل قسم ومدخل | ملفات تعريف StructureDefinition لكل مورد، منشورة في أدلة التنفيذ |
| المصطلحات | رموز أقسام LOINC، مدخلات SNOMED/ICD/RxNorm | نفس أنظمة الترميز، كـ CodeableConcept |
ما يعنيه الاختلاف عمليًا
من الناحية العملية، يكمن الاختلاف بين CDA و FHIR في أن CDA مناسب للمحتوى المكتوب مرة واحدة والمحفوظ بالكامل، مثل ملخص الخروج الموقع، بينما يناسب FHIR البيانات التي تنمو ويتم الاستعلام عنها، مثل سلسلة قياسات ضغط الدم. يمكن لمستقبل CDA العرض ولكنه يجب أن يقوم بالمصالحة للاستيراد؛ بينما يحصل مستقبل FHIR على موارد مشكلة بالفعل لتتوافق مع سجله الخاص.
ملخص الخروج هو بطبيعته مستند: يتم كتابته مرة واحدة، ويوقعه طبيب واحد، ويجب أن يكون قابلاً للتكرار بعد سنوات بالضبط كما تمت قراءته. سلسلة ضغط الدم هي بطبيعتها مجموعة من الموارد: تنمو كل يوم، ويتم رسمها وتصفيتها، ولا يوقعها أحد. يتعامل CDA مع الأول بشكل جيد والثاني بشكل سيء (ستعيد إرسال المستند بأكمله لكل قراءة جديدة). يتعامل FHIR مع الثاني أصليًا والأول من خلال آلية المستند الخاصة به.
الاختلاف العملي الآخر هو ما يمكن للمستقبل فعله. يمكن لمستقبل CDA دائمًا عرض المستند؛ يتطلب استيراد مدخلاته تسوية، قسمًا تلو الآخر. يحصل مستقبل FHIR على موارد في شكل سجله الخاص؛ تنتقل الأسئلة الصعبة إلى الهوية (هل هذا هو نفس المريض؟) والأصل (من أكد هذا ومتى؟). انظر مطابقة المرضى.
مستندات FHIR: نقطة الالتقاء
مستند FHIR هو حزمة مع type: "document" أول مدخل لها هو Composition. يلعب Composition دور رأس CDA وقائمة الأقسام: النوع (LOINC)، التاريخ، المؤلف، الموضوع، الوصي، الحالة، و section[] مع عنوان، ورمز، ونص سردي، وإشارات إلى الموارد التي تحمل البيانات.
{
"resourceType": "Bundle",
"type": "document",
"identifier": {"system": "urn:ietf:rfc:3986", "value": "urn:uuid:3f2d7a3e-…"},
"timestamp": "2026-03-14T10:15:00+01:00",
"entry": [
{"fullUrl": "urn:uuid:comp-1", "resource": {
"resourceType": "Composition", "status": "final",
"type": {"coding": [{"system": "http://loinc.org", "code": "60591-5", "display": "Patient summary Document"}]},
"subject": {"reference": "urn:uuid:pat-1"},
"date": "2026-03-14T10:15:00+01:00",
"author": [{"reference": "urn:uuid:prac-1"}],
"title": "Patient summary",
"section": [{
"title": "Allergies and intolerances",
"code": {"coding": [{"system": "http://loinc.org", "code": "48765-2"}]},
"text": {"status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>Penicillin: rash</p></div>"},
"entry": [{"reference": "urn:uuid:allergy-1"}]
}]
}},
{"fullUrl": "urn:uuid:pat-1", "resource": {"resourceType": "Patient", "id": "pat-1"}},
{"fullUrl": "urn:uuid:prac-1", "resource": {"resourceType": "Practitioner", "id": "prac-1"}},
{"fullUrl": "urn:uuid:allergy-1", "resource": {"resourceType": "AllergyIntolerance", "id": "allergy-1", "patient": {"reference": "urn:uuid:pat-1"}, "code": {"coding": [{"system": "http://snomed.info/sct", "code": "764146007", "display": "Penicillin"}]}}}
]
}
ملخص المريض الدولي هو بالضبط هذا: ملف تعريف مستند FHIR، مع توأم CDA للأنظمة التي لا تزال بحاجة إليه. انظر أيضًا حزمة FHIR مشروحة.
التحويل بينهما
يعمل التحويل بين CDA و FHIR في كلا الاتجاهين مع وجود قيود. يقوم دليل التنفيذ HL7 C-CDA on FHIR بتعيين أنواع المستندات والأقسام والإدخالات إلى ملفات تعريف وتكوينات (Composition profiles and resources)؛ وتصبح الأقسام التي تحتوي على سرد فقط نصًا بدون بيانات. يعمل التحويل من FHIR إلى CDA للموارد التي تتناسب مع قوالب C-CDA. في أي من الاتجاهين، يجب الاحتفاظ بالمستند الأصلي كـ DocumentReference مع Provenance.
- CDA → FHIR: دليل التنفيذ C-CDA on FHIR الخاص بـ HL7 يربط أنواع المستندات والأقسام الأمريكية بملفات تعريف Composition؛ تربط المدخلات بالموارد (Problem Concern Act → Condition، Medication Activity → MedicationStatement، Result Observation → Observation). الربط حتمي للمحتوى من المستوى 3 ذي القوالب الجيدة وفاقد للمعلومات للأقسام السردية فقط، والتي تصبح نصًا بدون بيانات.
- FHIR → CDA: ممكن للمستندات التي تتناسب مواردها مع قوالب C-CDA. الموارد الحرة لـ FHIR التي لم تكن مخصصة كمستند (تدفق ملاحظات قابلة للارتداء) لا تصبح CDA منطقيًا.
- احتفظ بالأصل. في أي اتجاه تقوم بالتحويل، قم بتخزين المصدر كما تم استلامه، كـ DocumentReference، ودع Provenance يشير من الموارد المحولة إليه. التحويل هو عرض، وليس استبدالًا.
متى لا يزال CDA هو الإجابة الصحيحة
لا يزال CDA هو الحل الصحيح عندما يتطلب الطرف المستقبل ذلك (انتقالات الرعاية في الولايات المتحدة، ملخص المريض والوصفة الإلكترونية في MyHealth@EU، العديد من سجلات المستندات الوطنية)، عندما يكون المحتوى قانونيًا مستندًا يجب توقيعه وحفظه بالكامل، أو عندما تكون البنية التحتية للشريك هي IHE XDS، التي تفهرس المستندات بدلاً من الموارد. بخلاف ذلك، ابدأ بـ FHIR.
عندما يطلب الطرف المستقبل ذلك (الانتقالات الأمريكية للرعاية، ملخص المريض الأوروبي MyHealth@EU والوصفات الإلكترونية اليوم، العديد من سجلات المستندات الوطنية)؛ عندما يكون المحتوى مستندًا قانونيًا يجب توقيعه وحفظه بالكامل؛ عندما تكون البنية التحتية للشريك هي IHE XDS، التي تسجل المستندات وليس الموارد. في كل حالة أخرى، ابدأ بـ FHIR وأنتج مستند FHIR حيث يلزم مستند.
صفحات ذات صلة
- CDA و C-CDA مشروحة
- حزمة FHIR مشروحة
- ملخص المريض الدولي
- HL7 مقابل FHIR
- DocumentReference مقابل DiagnosticReport مقابل Binary
- مطابقة المرضى
مصادر
- HL7 FHIR R4: المستندات
- HL7 FHIR R4: Composition
- دليل تنفيذ HL7 C-CDA on FHIR
- HL7 FHIR: مقارنة مع CDA (ملحق)
- HL7 FHIR: دليل ملخص المريض الدولي
الأسئلة الشائعة
هل مستند FHIR مجرد CDA بتنسيق JSON؟
لا. إنه يشارك المبادئ (كامل، موقع، قابل للقراءة بشريًا، مع رأس) ولكن محتواه هو موارد FHIR عادية، لذا يمكن أن يعيش نفس Observation في مستند ويتم تقديمه بواسطة واجهة برمجة التطبيقات. في CDA، يوجد إدخال فقط داخل مستنده.
هل يمكنني توقيع مستند FHIR؟
نعم. يحتوي Bundle.signature على توقيع رقمي على الحزمة، وتصف أدلة IPS والوطنية كيفية القيام بذلك. في الممارسة العملية، تعتمد العديد من عمليات النشر على أمان النقل والأصل بدلاً من التوقيعات.
هل لدى FHIR templateId؟
المعادل هو meta.profile، وهي قائمة بعناوين URL القياسية لتعريفات الهيكل التي يدعي المورد الامتثال لها. تتحقق المدققات من الامتثال بالطريقة التي تتحقق بها مخططات CDA من القوالب.
ماذا يجب أن يختار برنامج وطني جديد؟
تختار البرامج الحديثة (تنسيق تبادل EHDS، قواعد وصول المرضى الأمريكية، IPS) FHIR، مع مستندات FHIR للملخصات والرسائل، وتحتفظ بمسار CDA فقط للشركاء القدامى.
جرّبه مجانًا في بيئة الاختبار
أول طلب FHIR خلال 5 دقائق. واجهة برمجة تطبيقات HL7 FHIR R4 مع موافقة المريض مدمجة: جربها في بيئة الاختبار، ثم اربط تطبيقك الخاص أو نظام عيادتك.
مجاني · 30 مريضًا اصطناعيًا · دون بطاقة

