حالة الموعد وحالة المشارك حقلان مختلفان في FHIR R4.0.1. إذا رأى المساعد أن مشاركا قبل الدعوة، فلا يستبدل بها حالة الموعد كله. نقرأ مثال بطاقة إدارية مؤلفة تضم مشاركين، ثم نفصل رد كل منهما عن القرار العام وعن حدوث اللقاء، دون حجز أو إرسال دعوة.
الخلاصة السريعة
لا؛ قبول مشارك يصف رده هو، بينما لحالة الموعد حقل مستقل يقرأ وفق السجل وقواعد النظام.
- يفصل FHIR R4.0.1 حالة Appointment عن participant.status لكل مشارك، ويصف جمع الردود لتحديث الحالة العامة. [1] لا نخلط الحقلين.
- في بطاقتنا حالة الموعد pending، وأ قبل، وب ما زال needs-action؛ لا يكتب المساعد أن الموعد booked من قبول أ وحده.
- رد مرتبط بموعد م لا يغير تلقائيا موعدا آخر أو تفاصيل زمن جديد؛ احتفظ بمعرف الموعد والمشارك والنسخة التي يخصها الرد.
- حتى booked لا يكون في مثالنا سجلا أن اللقاء وقع؛ احفظ الحالة العامة وردود المشاركين منفصلة، دون وعد بموعد أو ادعاء تنفيذ تحديث.
أي حقل يجيب عن أي سؤال؟
يعرض FHIR R4.0.1 حقل status للموعد وحقل status داخل كل participant. وفي نمط الطلب والرد توثق الردود ثم تحدث الحالة العامة التي تجمعها. [1]
نسأل أولا: هل الجملة تصف الموعد أم شخصا مشاركا؟ إذا كانت قائمة الملخص تعرض اسمين، لا ننقل القيمة المقابلة لأحدهما إلى رأس القائمة. قد تكون كتابة accepted صحيحة في سطر وخاطئة حين تصبح وصفا للمجموع.
نقتصر على الإصدار المقروء، لا على كل تطبيق عيادة أو أحدث معيار. لا يبين اسم الأداة أو وجود مساعد ذكي القاعدة التي يعتمدها النظام لتثبيت الحالة؛ نراجع الحقول المرسلة والعقد الذي يخصها.
ماذا يقول السجل المؤلف فعلا؟
نؤلف موعد م بوقت معلن ومشاركين أ وب. الحقل العام pending، وحالة أ accepted، وحالة ب needs-action. هذه بطاقة تفسير بلا أسماء مرضى أو تفاصيل علاج؛ لم نستقبلها من نظام صحي.
يمكن للملخص أن يقول «قبل أ، وما زال رد ب يحتاج إجراء، وحالة م قيد الانتظار». أما «تأكد الموعد لأن أ قبله» فتضيف قرارا عاما يخالف البطاقة التي فرضناها. لا نغير الحقل كي يبدو الملخص نهائيا.
ولا نستخرج رفض ب من needs-action؛ البطاقة لم تسجل declined. كذلك لا نفترض سبب عدم رده أو وقت وصول الرد. نحافظ على اختلاف القبول والرفض والحاجة إلى إجراء بدل جمعها في نعم أو لا واحدة.
| العنصر المؤلف | الحقل | القيمة |
|---|---|---|
| الموعد م | الحالة العامة | pending |
| المشارك أ | حالة مشارك | accepted |
| المشارك ب | حالة مشارك | needs-action |
أي موعد وأي تفاصيل شملها الرد؟
نفترض بطاقة ثانية لوقت مختلف ومعرف ن. قبول أ في م ليس ردا لن لمجرد أن المشاركين أنفسهم. نحتاج إلى علاقة صريحة تربط الرد بالموعد الذي نلخصه، ولا نحمل الرد القديم إلى دعوة جديدة من تشابه العنوان.
وفي تغيير افتراضي داخل م نفسه، يصل سجل بتفاصيل زمن جديدة دون سجل ردود يخصها. لا نفترض أن كل قبول سابق شمل التغيير. نذكر النسخة التي نملكها والربط الذي تأكد أو بقي ناقصا، دون اختراع إجراء لكل نظام.
تساعد هذه المراجعة على منع تسوية القيم المنفصلة، لكنها لا تنفذ إرسالا أو تحديثا. إذا قدم النظام الحالة الجديدة فعليا، نقرأها مع مرجعها؛ لا نستبدل جملة اقتراح من المساعد بسجل الخدمة.
هل الحالة تعني أن اللقاء حدث؟
نؤلف نسخة لاحقة تقول booked، ونعلن أنها حالة إدارية للموعد. لا تحتوي هذه البطاقة على سجل حضور أو بدء خدمة؛ لذلك لا نكتب أن اللقاء جرى أو أن مشاركا تلقى رعاية من كلمة الحجز وحدها.
يحافظ تقريرنا المقترح على الحالة العامة، وردود المشاركين، والموعد ووقته، والمواد التي استند إليها. لا يجعل تحديث أحد السطور شهادة على بقية السطور، ولا يعلن اكتمال إجراء لم تظهر نتيجته.
لم نحجز عيادة أو نرسل إشعارا أو نفحص استعداد نظام فعلي. تفسر البطاقة إسناد الحالة في بنية موثقة، مع إبقاء قبول الفرد وقرار الموعد وحدوث اللقاء أسئلة مختلفة.
المصادر ومتابعة القراءة
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.