شرح مورد المريض في FHIR: المعرفات، الأسماء، البيانات الديموغرافية والروابط، مع مثال صالح

إجابة مختصرة: Patient هو مورد FHIR الذي يصف الشخص الذي يتلقى الرعاية: هويته إداريًا، وليس ما يعاني منه. يحمل معرفات (أرقام السجلات الطبية، الهويات الوطنية)، أسماء، معلومات الاتصال telecom، الجنس الإداري، تاريخ الميلاد، العنوان، الحالة الاجتماعية، التواصل (اللغات)، الممارس العام، المنظمة المسؤولة و روابط لسجلات Patient أخرى لنفس الشخص. كل Observation، Condition، Encounter أو MedicationStatement يشير إليه من خلال subject أو patient. الحقائق السريرية لا تعيش أبدًا في Patient؛ بل تعيش في الموارد التي تشير إليه.

مثال صالح لـ FHIR R4

يحتاج مورد FHIR R4 صالح للمريض (Patient) إلى نوع المورد (resourceType) فقط، ولكن في الواقع يحتوي على مُعرّف واحد على الأقل مع نظام وقيمة، واسم مع أجزاء العائلة والاسم الأول، وجنس إداري وتاريخ ميلاد. المثال أدناه يدعي أيضًا ملف تعريف المريض IPS (IPS Patient profile) في meta.profile ويضيف معلومات الاتصال، العنوان، اللغة المفضلة، الطبيب العام، والمنظمة المسؤولة.

{
  "resourceType": "Patient",
  "id": "example",
  "meta": {"profile": ["http://hl7.org/fhir/uv/ips/StructureDefinition/Patient-uv-ips"]},
  "identifier": [{
    "use": "usual",
    "type": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MR"}]},
    "system": "https://hospital.example.org/mrn",
    "value": "MRN-00012345"
  }],
  "active": true,
  "name": [{"use": "official", "family": "Doe", "given": ["Jane", "Marie"], "prefix": ["Ms"]}],
  "telecom": [{"system": "email", "value": "[email protected]", "use": "home"}],
  "gender": "female",
  "birthDate": "1980-05-23",
  "address": [{"use": "home", "line": ["12 High Street"], "city": "Leeds", "postalCode": "LS1 4AB", "country": "GB"}],
  "communication": [{"language": {"coding": [{"system": "urn:ietf:bcp:47", "code": "en-GB"}]}, "preferred": true}],
  "generalPractitioner": [{"reference": "Practitioner/gp-42"}],
  "managingOrganization": {"reference": "Organization/hospital"}
}

العناصر المهمة

عناصر المريض الأكثر أهمية للتوافقية هي المُعرّف (identifier) (مع النظام والقيمة والنوع)، الاسم (name) (مع الاستخدام والعائلة والاسم الأول)، الجنس الإداري (administrative gender)، تاريخ الميلاد (birthDate)، الوفاة (deceased)، النشاط (active)، الاتصال (contact)، والربط (link). المُعرّفات والأسماء توجه المطابقة بين الأنظمة، والجنس وتاريخ الميلاد هي حقائق إدارية، والربط يسجل كيف قام فهرس المريض الرئيسي بربط سجلات مكررة لشخص واحد.

• identifier هي قائمة، كل منها يحتوي على system (من أصدره) و value. type يحدد نوع المعرف: MR رقم السجل الطبي، NI معرف وطني، PPN جواز سفر، SS رقم الضمان الاجتماعي، من جدول HL7 0203. عادة ما يكون لدى المريض عدة معرفات؛ رقم السجل الطبي للمستشفى والهوية الوطنية كلاهما صالحان، والأنظمة تتطابق بناءً عليهما.
• name هي أيضًا قائمة تحتوي على use: official رسمي، usual معتاد، nickname اسم مستعار، maiden اسم العائلة قبل الزواج، old قديم. family هو سلسلة نصية واحدة؛ given هي قائمة. تُترك النصوص والنسخ الصوتية وترتيب الأسماء لدليل التنفيذ الخاص بالبلد.
• gender هو الجنس الإداري بأربعة قيم: male ذكر، female أنثى، other آخر، unknown غير معروف. إنه ما يقوله السجل، ويستخدم للمطابقة والنماذج. الجنس السريري، الهوية الجنسية والضمائر تذهب في امتدادات أو Observations، والتي قام FHIR R5 ومشروع Gender Harmony بتنظيمها.
• birthDate هو تاريخ، اختياريًا السنة فقط أو السنة والشهر عندما يكون التاريخ الدقيق غير معروف. امتداد patient-birthTime يضيف الوقت للمواليد الجدد.
• deceased[x] هو قيمة منطقية أو تاريخ ووقت. active بقيمة false يحدد سجلًا يجب عدم استخدامه بعد الآن (مكرر، تم نقله)، دون حذفه.
• contact تسرد الأشخاص الذين يمكن الاتصال بهم (الأقارب المقربون، الوصي)، مع رمز العلاقة؛ هم ليسوا موارد Patient بحد ذاتهم. الوالد الذي هو أيضًا مريض هو RelatedPerson يشير إلى كليهما.
• link يربط سجلات Patient التي تخص نفس الشخص: replaced-by و replaces بعد الدمج، refer إلى السجل الموثوق، seealso لسجل في نظام آخر. هذه هي الطريقة التي يعبر بها فهرس المرضى الرئيسي عن قراراته في FHIR؛ انظر مطابقة المرضى.

ما تضيفه الملفات التعريفية الوطنية

تحوّل ملفات FHIR التعريفية الوطنية والدولية مورد المريض الأساسي (Patient resource) غير المحدد بوضوح إلى شيء قابل للاستخدام بجعل العناصر إلزامية وإضافة امتدادات خاصة بالبلد. يتطلب US Core المُعرّف والاسم والجنس ويضيف امتدادات للعرق والإثنية وجنس الولادة؛ يتطلب ملف تعريف IPS للمريض الاسم والجنس وتاريخ الميلاد؛ تحدد الملفات التعريفية الوطنية أنظمة المُعرّفات وتنسيقات العناوين.

المورد الأساسي يجعل كل شيء اختياريًا تقريبًا. الملفات التعريفية تجعله قابلاً للاستخدام:

السجل الذي سيعبر الحدود يجب أن يفي بالملف التعريفي على كل جانب، مما يعني عمليًا حمل المعرف الوطني ورقم السجل الطبي، اسم رسمي كامل وتاريخ ميلاد كامل. انظر أدلة تنفيذ FHIR.

العمليات التي ستستخدمها

عمليات FHIR الأكثر استخدامًا مع المريض هي البحث عن طريق المُعرّف أو عن طريق البيانات الديموغرافية (GET /Patient مع معلمات المُعرّف أو اسم العائلة أو تاريخ الميلاد)، عملية $everything، التي تُرجع المريض وكل مورد يشير إليه، وعملية $match، التي تطلب من خوارزمية المطابقة الخاصة بالخادم تحديد التكرارات المحتملة. يجري حاليًا توحيد عملية $merge في FHIR R5.

• GET /Patient?identifier=https://hospital.example.org/mrn|MRN-00012345 يبحث عن مريض بواسطة المعرف؛ ?family=doe&birthdate=1980-05-23 بواسطة البيانات الديموغرافية.
• GET /Patient/{id}/$everything يعيد المريض وكل مورد يشير إليه، مقسمًا إلى صفحات، وهي الطريقة التي يتم بها تصدير سجل كامل.
• $match (حيثما كان مدعومًا) يطلب من خوارزمية المطابقة الخاصة بالخادم تحديد التكرارات المحتملة؛ $merge قيد التوحيد القياسي في R5.

الأخطاء التي تكسر سجلات المرضى

الأخطاء التي غالبًا ما تكسر سجلات FHIR للمرضى هي تخزين هوية وطنية في معرف المورد (resource id) بدلاً من المُعرّف (identifier)، وإغفال نظام المُعرّف (identifier.system) بحيث تتصادم القيم من مستشفيات مختلفة، ووضع الاسم بالكامل في نص دون أجزاء العائلة والاسم الأول، واستخدام الجنس الإداري للجنس السريري، وتحرير سجل مدمج في مكانه بدلاً من ربطه وتعطيله.

• وضع المعرف الوطني في id. معرف المورد id ينتمي إلى الخادم وقد يتغير عند الاستيراد؛ المعرفات تنتمي إلى identifier.
• name واحد مع كل شيء في text وبدون family/given، مما يؤدي إلى فشل عمليات البحث حسب اسم العائلة.
• استخدام gender للجنس السريري، أو تعيينه إلى unknown لأن النموذج لم يكن به حقل.
• فقدان identifier.system، مما يؤدي إلى تضارب قيم MRN-1 من مستشفيين.
• تعديل Patient في مكانه عند حدوث دمج، بدلاً من الربط وتعطيله.

في Anpheros

يمثل Anpheros كل شخص، صاحب الحساب وكل ملف تعريف عائلي، كمورد FHIR للمريض (FHIR Patient resource) على منصة Anpheros (Anpheros Platform)، وكل سجل تضيفه العيادة عبر واجهة برمجة التطبيقات (API) يشير إلى هذا المريض. تُحتفظ بمعرفات العيادات كمُعرّفات إضافية بنظام العيادة الخاص بها، وتبقى البيانات الديموغرافية التي يدخلها الشخص كبيانات إدارية لا يُستنتج منها أي شيء سريري.

عندما ترسل العيادة مُعرّفها الخاص، يتم تخزينه كـ identifier إضافي مع نظام العيادة، بحيث يمكن العثور على نفس الشخص من أي من الجانبين. البيانات الديموغرافية التي أدخلها الشخص في التطبيق هي الاسم usual والبيانات الإدارية؛ لا يستنتج السجل أي شيء سريري منها أبدًا.

صفحات ذات صلة

• مطابقة المرضى وفهرس المرضى الرئيسي
• أدلة تنفيذ FHIR
• شرح FHIR Encounter
• شرح FHIR Condition
• شرح بحث FHIR
• مثال Patient على موقع المطورين

مصادر

• HL7 FHIR R4: Patient
• HL7 FHIR R4: Patient $everything
• HL7 Terminology: identifier type codes (v2-0203)
• HL7 US Core: Patient profile
• HL7 IPS: Patient profile

الأسئلة الشائعة

هل Patient هو نفسه Person في FHIR؟

لا. Person هو مورد إداري يربط نفس الإنسان عبر الأدوار (مريض هنا، ممارس هناك، شخص ذو صلة في مكان آخر). الموارد السريرية تشير إلى Patient، وليس Person أبدًا.

أين تذهب الحساسيات والحالات؟

في موارد AllergyIntolerance و Condition التي تشير إلى Patient. Patient نفسه يحتوي فقط على البيانات الإدارية.

كيف أسجل مولودًا جديدًا بدون اسم؟

باسم يكون استخدامه temporary أو فارغًا، و birthDate مع امتداد patient-birthTime، و link لسجل الأم من خلال RelatedPerson أو امتداد patient-mothersMaidenName، كما تحدد الملفات التعريفية الوطنية.

هل يمكن مشاركة مورد Patient واحد بين مستشفيين؟

كل نظام يحتفظ بمورد Patient الخاص به بمعرفه الخاص؛ يتشاركون المعرفات (معرف وطني) وقد يربطون السجلات. المطابقة عبر الأنظمة هي وظيفة فهرس المرضى الرئيسي، وليس المورد.

Anpheros Platform

جرّبه مجانًا في بيئة الاختبار

أول طلب FHIR خلال 5 دقائق. واجهة برمجة تطبيقات HL7 FHIR R4 مع موافقة المريض مدمجة: جربها في بيئة الاختبار، ثم اربط تطبيقك الخاص أو نظام عيادتك.

أنشئ بيئة اختبار مجانيةاقرأ أدلة المطورين →

مجاني · 30 مريضًا اصطناعيًا · دون بطاقة

بقلم

فريق Anpheros

تبني Anpheros سجلًا طبيًا يتحكم فيه المريض ويمكن مشاركته مع أي عيادة، على منصة HL7 FHIR R4، مقرها في الاتحاد الأوروبي. تساعدك هذه الأدلة على فهم وتنظيم صحتك؛ ولا تغني عن استشارة طبيبك.

عن Anpheros →