تقنية

بطاقة صحية يرتبها المساعد: هل اسم المرافق هو اسم المريض؟

رسم توضيحي: السجل ر: اسم رامي؛ مرجع patient إلى م؛ السجل م: اسم سلمى؛ اسمان لدورين مختلفين
مخطط من إعداد بحر العلوم. بطاقات مؤلفة؛ المرجع ليس إثبات هوية أو صلاحية

اسم الشخص المرتبط ومرجع المريض يظهران في سجل واحد لكنهما يخصان دورين. نراجع تمثيل RelatedPerson في FHIR R4.0.1 بمعلومات مؤلفة، حتى لا يضع المساعد اسم مرافق في خانة الشخص الذي يتلقى الرعاية. المقصود تفسير حقلين موثقين، وليس كشف هوية مريض أو معالجة ملف عيادة.

الخلاصة السريعة

لا؛ في هذا التمثيل اسم RelatedPerson يصف الشخص المرتبط، ومرجع patient يحدد المريض الذي يرتبط به السجل.

  • يصف FHIR R4.0.1 شخصا مرتبطا بالمريض ليس هدف الرعاية المباشر، ويفصل اسمه عن مرجع المريض. [1] هذا نطاق الإصدار المقروء.
  • في بطاقة مؤلفة اسم رامي يخص السجل ر، ومرجعه يشير إلى المريض م؛ لا نستبدل اسم م برامي، ولا نعرف اسم م من المرجع وحده إذا لم يصل سجله.
  • relationship يصف طبيعة العلاقة؛ لا نخترع «أب» من تشابه اسمين. ولجهة اتصال المريض يعرض الدليل Patient.contact؛ قد يجمع فرد الدورين دون تطابق كل سجل اتصال وRelatedPerson. [1]
  • احتفظ بالمعرفات والأدوار ومواضع الغياب؛ لا تستنتج من الارتباط صلاحية وصول أو موافقة أو تحقق هوية، ولم نفتح ملفا صحيا أو نفذ نقل بيانات.

عمن تتحدث بطاقة RelatedPerson؟

في FHIR R4.0.1 يصف RelatedPerson شخصا يشارك في رعاية المريض دون أن يكون هدفها المباشر. يخص name ذلك الشخص، ويربط patient السجل بمورد Patient. [1]

نذكر الإصدار لأننا نفسر عقدا محددا، ولا نزعم أنه أحدث إصدار أو أن كل نظام صحي يستعمل البنية نفسها. قد يطلب محرر من المساعد تلخيص بطاقة مرسلة؛ يبدأ بالفصل بين اسم صاحب البطاقة واسم الشخص المشار إليه.

وجود الحقلين داخل الكائن نفسه لا يدمج صاحبيهما. يقترح المساعد صياغة تبين الدور، بدلا من اختيار أول اسم مرئي وإعلانه اسم المريض. هذه قراءة وثائق تقنية وليست مطابقة أشخاص حقيقيين.

كيف نتتبع اسمين دون تبديلهما؟

نؤلف سجل ر من نوع RelatedPerson باسم رامي، ونضع في patient مرجعا إلى المريض م. وفي بطاقة منفصلة مؤلفة، يرد اسم سلمى في سجل م. الأسماء والمعرفات للتفسير، وليست بيانات صحية.

يجوز لملخص هذا الملف أن يذكر رامي بوصفه الشخص المرتبط بسجل سلمى، لأننا قدمنا المرجع والبطاقة الثانية صراحة. لو نسخ الاسم رامي إلى حقل اسم م، فقد بدل الدور رغم أن كتابة الحروف صحيحة.

وفي نسخة ثانية نحذف بطاقة م من المواد المتاحة ونبقي المرجع. عندئذ نعرف إلى أي معرف يشير ر، لكن اسم المريض غير متاح في الملف. لا نملأه من رامي، ولا نستنتج أن المريض بلا اسم.

عنصر مؤلفالدورالقيمة
ر.nameاسم الشخص المرتبطرامي
ر.patientمرجع المريضم
م.name في البطاقة الثانيةاسم المريضسلمى

هل نعرف القرابة من الاسم أو الاتصال؟

يوثق الحقل relationship طبيعة العلاقة. ويخصص الدليل Patient.contact لمعلومات جهات اتصال المريض، مع إمكان أن يكون الفرد جهة اتصال وشخصا مرتبطا معا. [1]

لا يحتوي مثالنا على قيمة للعلاقة، لذلك لا نسمي رامي أبا أو أخا أو زوجا. حتى إذا تشابه لقبان، لم تقدم بطاقة التمرين هذه الصفة. لو وصلت قيمة علاقة معلنة، نسجلها مع مصدرها، دون تحويلها إلى تحقق مستقل من القرابة.

كما لا نحول كل رقم هاتف في قسم الاتصال إلى مورد RelatedPerson تلقائيا. نقرأ نوع العنصر الذي قدمه النظام. تشابه حقول الاسم والهاتف لا يثبت أن دورين في عقد البيانات مترادفان أو أنهما يشيران إلى الشخص نفسه.

ما الذي لا يمنحه هذا الارتباط؟

نقترح ملخصا يحتفظ بمعرف ر ومعرف م ونوع المرجع والاسم الذي يخص كل واحد وما بقي مجهولا. يساعد ذلك على مراجعة نقل الحقول قبل اعتماده، دون نشر بيانات حقيقية أو إدخالها إلى خدمة.

لم يقدم الملف سياسة وصول أو موافقة. لا نستخرج من وجود المرجع حكما أن ر يستطيع قراءة سجل م، أو أن م وافق على فعل، أو أن الهوية تحققت. هذه معان تحتاج أدلتها وإجراءاتها المستقلة ولا ينشئها الحقل من تلقاء نفسه.

قد يكون الإنسان مريضا في سياق آخر؛ وصف دوره في هذا السجل لا ينفي ذلك. يفسر المقال إسناد الاسم والمرجع في تمثيل معلوم فقط، ولا يصنف الناس أو يقدم قرارا طبيا أو قانونيا.

المصادر ومتابعة القراءة

  1. HL7 FHIR R4.0.1: RelatedPerson (يفتح في نافذة جديدة)hl7.org

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.