طلب الدواء وحالة سجل إعطائه ليسا سطرا واحدا. يمكن للمساعد عد أسماء موارد في ملف ثم إعلان عدد إعطاءات مكتملة، مع أن بعضها يحمل not-done أو unknown. نفسر علاقة موثقة في FHIR R4.0.1 من بطاقات مؤلفة، دون أسماء أدوية أو جرعات أو بيانات أشخاص أو قرار علاجي.
الخلاصة السريعة
لا؛ MedicationRequest يمثل طلبا، وMedicationAdministration يمثل سجل حدث له حالة. اسم المورد أو ارتباطه بطلب لا يجعل كل حالة completed.
- يصف FHIR R4.0.1 MedicationRequest طلب التزويد والتعليمات، وMedicationAdministration سجل حدث الإعطاء. [1][2] قراءة الطلب لا تستبدل قراءة سجل الحدث.
- في ملفنا المؤلف ثلاث بطاقات إعطاء: completed وnot-done وunknown؛ بطاقة واحدة مكتملة بحسب الملف، لا ثلاث، والمجهول لا يحول إلى نفي أو اكتمال.
- يتيح MedicationAdministration مرجع request إلى MedicationRequest، وهو اختياري في البنية. [2] غياب المرجع لا يجيز إسناد البطاقة إلى طلب قريب في القائمة.
- احتفظ بنوع المورد والحالة والمعرف والربط وحدود الملف؛ العدد المقروء لا يثبت اكتمال جميع أحداث الواقع أو صحة إعطاء، ولم ننفذ إجراء أو نقدم توجيه جرعة.
طلب أم سجل حدث؟
يصف FHIR R4.0.1 MedicationRequest طلب التزويد بالدواء وتعليمات إعطائه. [1] ويصف MedicationAdministration حدث تناوله أو إعطائه، مع حقل حالة. [2]
نذكر الإصدار المقروء تحديدا، ولا نسميه أحدث إصدار. نحتاج نوع المورد لنعرف سؤال البطاقة: ماذا طلب أم ماذا سجل عن حدث؟ يظل هذا الفرق قائما ولو ربط الملف الموردين بمعرف واحد.
نسمي دواء المثال بالرمز س فقط، دون كمية أو طريق إعطاء أو وصفة. غرض القراءة إسناد معنى الحقول في سجل افتراضي، وليس تقرير استعمال مادة أو التحقق من مناسبة علاج.
هل كل بطاقة إعطاء تعني اكتمالا؟
تتضمن الحالات الموثقة لـMedicationAdministration completed وnot-done وunknown إلى جانب حالات أخرى. [2]
نؤلف طلب ط وثلاث بطاقات مرتبطة به: إ 1 تحمل completed، وإ 2 تحمل not-done، وإ 3 تحمل unknown. نقرأ عدد البطاقات ثلاثة، وعدد الموسوم بالمكتمل واحدة. لا نحذف إ 2 وإ 3 من سجل المراجعة كي يبدو الملف أقصر.
ولا نحول unknown إلى not-done أو completed. هذه حالة مختلفة في بطاقتنا، لا صفرا لعدد أحداث العالم. لم نعلن أيضا أن البطاقات الثلاث تغطي جميع ما حدث خارج الملف.
| بطاقة مؤلفة | الحالة | هل تعد مكتملة في ملفنا؟ |
|---|---|---|
| إ 1 | completed | نعم |
| إ 2 | not-done | لا |
| إ 3 | unknown | لم تسجل مكتملة؛ الحالة مجهولة |
أي طلب يرتبط بأي سجل؟
يوثق حقل request مرجعا اختياريا إلى MedicationRequest. [2]
في ملفنا الأول قدمنا المرجع إلى ط لكل بطاقة. إذا حذفت نسخة ثانية المرجع من إ 3، فلا نعيده من تشابه رمز الدواء أو قرب السطر من ط. نذكر أن الربط غير متاح في النسخة التي نقرأها.
ولو ظهر طلب آخر ن للرمز س نفسه، لا ننقل إ 1 إليه كي نملأ فراغا. نحتفظ بمعرف كل مورد والمرجع المرسل، ونفصل غياب العلاقة في المواد عن إثبات أنها غير موجودة في أي نظام.
المرجع يجعل تقرير الملف أكثر قابلية للتتبع، لكنه لا يغير حالة إ 2 إلى completed. العلاقة بين الطلب والحدث لا تلغي الاختلاف بين حقول الحدث نفسه.
ما حدود العدد الذي يمكن تلخيصه؟
نقترح عنوانا دقيقا: «بطاقة إعطاء واحدة تحمل completed في المواد المتاحة». هذه عبارة عن الملف، لا شهادة ميدانية أنه كامل أو أن الحدث نفذ بصورة صحيحة. لم نتحقق من أشخاص أو خدمة.
يحفظ الملخص بطاقات الحالات الأخرى بدل دمجها في إجابة نعم أو لا عن الطلب. إذا تغيرت مادة المصدر، نعيد القراءة مع النسخة والمعرفات؛ لا ننسب تحديثا إلى نظام لأن المساعد أعاد صياغة جدول.
لم نرسل طلب دواء أو نعط مادة أو نختبر API. يوضح المثال نوع المورد وحالته وربطه وحدود التغطية فقط. لا يستخرج مقدار جرعة أو إجراء لاحق من هذه البطاقات، ولا يستبدل بها قرارا طبيا.
المصادر ومتابعة القراءة
- HL7 FHIR R4.0.1: MedicationRequest (يفتح في نافذة جديدة)hl7.org
- HL7 FHIR R4.0.1: MedicationAdministration (يفتح في نافذة جديدة)hl7.org
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.