إجابة مختصرة: اللقاء (Encounter) هو تفاعل واحد بين المريض والنظام الصحي: زيارة عيادة خارجية، إقامة في المستشفى، حضور في قسم الطوارئ، استشارة عبر الفيديو، زيارة منزلية. يسجل متى (period)، في أي بيئة (class: عيادة خارجية، داخل المستشفى، طوارئ، رعاية صحية منزلية، افتراضي)، حالة الزيارة (مخطط لها → قيد التنفيذ → مكتملة)، من شارك، لماذا (reasonCode) و ما تم تشخيصه (diagnosis، ويربط بالحالات Conditions). الملاحظات (Observations)، الإجراءات (procedures)، طلبات الأدوية (medication orders) والمستندات (documents) تشير إلى اللقاء الذي تنتمي إليه، وبهذه الطريقة يمكن قراءة السجل زيارة بزيارة.
مثال صالح لـ FHIR R4
يتطلب مورد لقاء FHIR R4 صالحًا فقط الحالة والفئة، ولكن المورد المفيد يحمل أيضًا الموضوع والفترة والنوع والمشاركين والسبب والتشخيصات التي وضعها. المثال أدناه هو استشارة متنقلة مكتملة لمرض السكري من النوع 2، مع مقدم خدمة أساسي، وتشخيص شكوى رئيسية مصنفة أولاً، وموقع، والمؤسسة المسؤولة.
{
"resourceType": "Encounter",
"id": "visit-2026-03-14",
"status": "finished",
"class": {"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "AMB", "display": "ambulatory"},
"type": [{"coding": [{"system": "http://snomed.info/sct", "code": "11429006", "display": "Consultation"}]}],
"serviceType": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/service-type", "code": "165", "display": "Diabetes Education"}]},
"subject": {"reference": "Patient/example"},
"participant": [{
"type": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType", "code": "PPRF", "display": "primary performer"}]}],
"individual": {"reference": "Practitioner/gp-42"}
}],
"period": {"start": "2026-03-14T09:00:00+01:00", "end": "2026-03-14T09:25:00+01:00"},
"reasonCode": [{"coding": [{"system": "http://snomed.info/sct", "code": "44054006", "display": "Type 2 diabetes mellitus"}]}],
"diagnosis": [{
"condition": {"reference": "Condition/t2dm"},
"use": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/diagnosis-role", "code": "CC", "display": "Chief complaint"}]},
"rank": 1
}],
"location": [{"location": {"reference": "Location/clinic-3"}, "status": "completed"}],
"serviceProvider": {"reference": "Organization/hospital"}
}
الحالة: دورة الحياة
تنتقل حالة لقاء FHIR عبر مخطط لها، تم الوصول إليها، تم فرزها، قيد التقدم، في إجازة، وتم الانتهاء منها، مع إلغاء، تم إدخالها عن طريق الخطأ، وغير معروف كالمخارج الأخرى. يحتفظ عنصر statusHistory بكل حالة سابقة مع فترتها، لذلك تظهر الإقامة في المستشفى متى وصل المريض وتم قبوله وغادر. اللقاء هو التفاعل نفسه، وليس الموعد الذي حجزه.
planned (محجوز، لم يبدأ بعد) → arrived → triaged (أقسام الطوارئ) → in-progress (قيد التنفيذ) → onleave (مريض داخل المستشفى في إجازة مؤقتة) → finished (مكتمل). cancelled (ملغى) و entered-in-error (تم إدخاله عن طريق الخطأ) تنهيه بطرق أخرى؛ unknown (غير معروف) موجود للاستيراد. statusHistory يحتفظ بالحالات السابقة مع فتراتها، لذا تظهر إقامة المستشفى متى وصل المريض، ومتى تم قبوله، ومتى غادر. لاحظ أن اللقاء (Encounter) ليس موعدًا (Appointment): الموعد هو الحجز؛ عندما يصل المريض، يتم إنشاء لقاء (Encounter) يشير إليه من خلال appointment.
الفئة: البيئة
تأتي class اللقاء من نظام HL7 v3 ActCode: AMB متنقل (خارج المستشفى)، IMP مقيم، EMER طوارئ، HH صحة منزلية، VR افتراضي (رعاية صحية عن بعد)، ACUTE و NONAC لأنواع فرعية للمقيمين، OBSENC ملاحظة، PRENC ما قبل القبول، SS إقامة قصيرة. يسجل classHistory التحويلات، على سبيل المثال حضور طارئ أصبح قبولًا.
العناصر الأخرى
بالإضافة إلى الحالة والفئة، يحمل لقاء FHIR النوع ونوع الخدمة (نوع الزيارة وخط الخدمة)، والمشارك (الأطباء بأدوارهم وفتراتهم)، ورمز السبب أو مرجع السبب، والتشخيص (الحالات المرتبطة مع الاستخدام والترتيب)، والاستشفاء (تفاصيل القبول والخروج)، وإدخالات الموقع بمرور الوقت، والطول، ومقدم الخدمة، والجزء من اللقاءات الفرعية.
- type و serviceType يحددان نوع اللقاء وخط الخدمة (أمراض القلب، تعليم مرض السكري)، مع رموز تختلف حسب البلد.
- participant يسرد الأطباء وغيرهم مع نوع المشاركة (المُدخل، الحاضر، المؤدي الأساسي، الاستشاري، المُحيل) والفترة التي شارك فيها كل منهم.
- reasonCode / reasonReference يقدمان سبب الزيارة؛ diagnosis يربط الحالات (Conditions) التي تم تأسيسها أو معالجتها، مع
use(تشخيص القبول AD، تشخيص الخروج DD، الشكوى الرئيسية CC، مرض مصاحب CM، فوترة) وrank(ترتيب). انظر شرح حالة FHIR Condition. - hospitalization يحمل تفاصيل القبول:
admitSource(إحالة من طبيب عام، طوارئ، تحويل)،dischargeDisposition(المنزل، مستشفى آخر، متوفى)،preAdmissionIdentifier(معرف ما قبل القبول)، النظام الغذائي والترتيبات الخاصة. - location يسرد الأماكن مع حالتها بمرور الوقت (مخطط لها، نشطة، محجوزة، مكتملة)؛ إضافة قسم جديد يضيف إدخالًا جديدًا.
- length هي المدة؛ serviceProvider المنظمة المسؤولة؛ partOf يربط لقاء فرعي (إقامة في قسم) بالقبول الذي ينتمي إليه.
ما تغير في R5
أعادت FHIR R5 تسمية Encounter.hospitalization إلى admission، ودمجت reasonCode و reasonReference في reason، وجعلت class قائمة من CodeableConcept (يمكن أن يحمل اللقاء عدة تصنيفات)، ونقلت participant.individual إلى actor، وقدمت EncounterHistory كمورد منفصل لتاريخ الحالة والفئة. لا تزال R4 هي الإصدار المستخدم في US Core ومعظم الأدلة الوطنية؛ انظر FHIR R4 مقابل R5.
التعيين من HL7 v2
تُعيّن رسائل HL7 v2 ADT إلى لقاء FHIR حسب نوع الحدث: A01 قبول ينشئ لقاء مقيم قيد التقدم، A03 خروج ينهيه مع period.end وتصرف الخروج، A02 تحويل يضيف إدخال موقع، A04 يسجل لقاء متنقل و A08 يحدثه. معظم البيانات تأتي من المقطع PV1، الذي يصبح رقم الزيارة Encounter.identifier.
ينشئ ADT^A01 (قبول) لقاءً بفئة IMP وحالة قيد التنفيذ؛ A03 (خروج) يضبط الحالة إلى مكتمل ويملأ period.end و dischargeDisposition؛ A02 (تحويل) يضيف إدخالًا لـ location؛ A04 (تسجيل عيادة خارجية) ينشئ لقاءً AMB؛ A08 يحدثه. يحمل PV1 معظم البيانات (فئة المريض في PV1-2، الموقع في PV1-3، الحاضر في PV1-7، رقم الزيارة في PV1-19، والذي يصبح Encounter.identifier). انظر شرح رسائل HL7 v2.
في Anpheros
تنشئ منصة Anpheros موارد لقاء FHIR بطريقتين: تكتب العيادات هذه الموارد عبر واجهة برمجة التطبيقات (API)، وتصبح زيارة الشخص المسجلة الخاصة به لقاءً مكتملًا بمجرد انتهاء الموعد. تشير النتائج والمستندات والملاحظات من تلك الزيارة إلى اللقاء، بحيث يمكن للشخص قراءة السجل زيارة تلو الأخرى، وكذلك أي عيادة يشاركها معها.
المواعيد المحجوزة في التطبيق هي موارد مواعيد حتى تحدث.
صفحات ذات صلة
- شرح حالة FHIR Condition
- شرح مورد FHIR Patient
- شرح رسائل HL7 v2: ADT و ORU
- FHIR R4 مقابل R5
- شرح FHIR DiagnosticReport
- مثال لقاء على موقع المطورين
المصادر
- HL7 FHIR R4: Encounter
- HL7 FHIR R5: Encounter
- HL7 Terminology: v3 ActCode (encounter class)
- HL7 Terminology: diagnosis-role code system
- HL7 US Core: Encounter profile
الأسئلة الشائعة
ما الفرق بين اللقاء (Encounter) والموعد (Appointment)؟
الموعد هو حجز لموعد مستقبلي؛ اللقاء هو التفاعل الذي حدث بالفعل (أو يحدث حاليًا). عندما يصل المريض، يتم إنشاء اللقاء ويشير إلى الموعد.
هل إقامة المستشفى لقاء واحد أم عدة لقاءات؟
عادةً لقاء واحد للقبول، مع إدخالات للموقع لكل قسم وسجل فئات لتغييرات البيئة. تنشئ بعض الأنظمة لقاءات فرعية لكل إقامة في قسم مرتبطة عبر partOf؛ تحدد الأدلة الوطنية ذلك.
أين يذهب ملخص الخروج؟
كمرجع للمستند (DocumentReference) أو كمستند FHIR يشير تركيبه (Composition) إلى اللقاء. يحتوي اللقاء نفسه على تصرف الخروج والتواريخ، وليس السرد.
هل كل ملاحظة (Observation) تحتاج إلى لقاء؟
لا. الملاحظات التي يسجلها المريض في المنزل، أو التي تصل من جهاز قابل للارتداء، ليس لها لقاء. تلك التي تم أخذها أثناء زيارة يجب أن تشير إليها حتى يمكن قراءة السجل حسب الزيارة.
جرّبه مجانًا في بيئة الاختبار
أول طلب FHIR خلال 5 دقائق. واجهة برمجة تطبيقات HL7 FHIR R4 مع موافقة المريض مدمجة: جربها في بيئة الاختبار، ثم اربط تطبيقك الخاص أو نظام عيادتك.
مجاني · 30 مريضًا اصطناعيًا · دون بطاقة

