السلوك المتوقع للمحدد الزائد لـ HL7 Accelerator

Question

خذ بعين الاعتبار مقطع PV1 التالي في رسالة HL7v2.

PV1|1|E|MYLOC||||55555^Doctor^Doc^D^^Dr^^DOCT|||||||HO||||ER||BC|||||||||||||||||||VALUE||REG|||201406270627||||||||55555^Doctor^Secondary^H^^Dr^^DOCT2|

هناك 52 حقلاً هناك.يرسل نظام Meditech الخاص بنا دائمًا الحقل 52 (PV1_52_OtherHealthcareProvider) على هذه الواجهة، والذي يمثله هنا 55555^Doctor^Secondary^H^^Dr^^DOCT2.لقد تم إعداده بحيث السماح بالمحددات الزائدة قيد التشغيل.كما ترون هناك محدد زائدة في هذا الجزء، لكن وهذا بعد الحقل الأخير في المقطع، والذي يصادف أنه يحتوي على البيانات الموضحة أعلاه.

سيكون هذا هو الحال دائمًا، حيث تقوم Meditech دائمًا بإلحاق محدد زائد على هذه الواجهة.

لا تحتوي أي من الشرائح الأخرى على بيانات في الحقل النهائي، لذلك لم نواجه هذه المشكلة معهم، على الرغم من وجود محددات زائدة لديهم.في الجزء PV1 نتلقى خطأ:

Error happened in body during parsing 
Error # 1
Segment Id: PV1
Sequence Number: 1
Error Number: 100
Error Description: Segment sequence error (Unexpected end of message body found)
Encoding System: HL79999

اتضح أن هذا يرجع إلى المحدد اللاحق، لأن إزالة المحدد يدويًا وإعادة الإرسال، لا يحدث الخطأ.أيضًا إذا قمت بتعديل المخطط لإضافة ملف غبي (PV1_53_ExtraField)، الرسالة مسموحة.

سؤالي هو هذا:ما هو السلوك المتوقع من السماح بالمحددات الزائدة في هذه الحالة؟هل من المفترض السماح بمحدد زائدة في الجميع الحالات، أم أنها لا تنطبق إلا على المقاطع التي يكون فيها الحقل النهائي خاليًا من البيانات (على سبيل المثال:حقول إضافية في نهاية الجزء)؟

Answer 1

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

أود أن أقترح التعامل مع هذا الأمر من خلال تلقي مكون خط الأنابيب ورفعه بدعم Microsoft

Answer 2

على الرغم من ذلك الإصدار القياسي للمراسلة HL7 2.6 لم تقم بتمديد مقطع PV1 بحقول أخرى وبالتالي كان الكود الأصلي الخاص بك صحيحًا من وجهة نظر دعم 52 حقل مقطع فقط

1. من الصحيح تمامًا توسيع بروتوكول المراسلة HL7 مع الحقول المخصصة والقطاعات المخصصة، بشرط أن يتم الاتفاق على هذا التمديد من قبل جميع الأطراف المعنية وتوثيقه في بيان المطابقة HL7 (يمكنك العثور على بعض الروابط التوضيحية هنا و هنا)

2. يجب أن يكون كود التحليل ومعالجة الرسائل متوافقًا مع الإصدارات القديمة وبعض الإصدارات المستقبلية من البروتوكول.يمكن تحديد عدد المقاطع وأسمائها وترتيبها وعدد الحقول وعدد المكونات في الحقول والتعامل معها ديناميكيًا.تم تصميم بناء جملة الرسالة لدعمه.أشياء مثل التشفير الثابت "سيكون هناك 52 حقلاً في مقطع PV1 بغض النظر عما يحتويه حقل إصدار HL7 MSH-12" ليس نهجًا جيدًا جدًا لأنه لن يتوسع

..ما هو السلوك المتوقع للسماح بالمحددات الزائدة في هذه الحالة؟..

السلوك المتوقع هو أن التطبيق الخاص بك لن يتعطل، ولن يمنع معالجة البيانات، إذا انتقلت البيانات عبر التعليمات البرمجية الخاصة بك إلى نظام آخر، فلا يجب عليك إسقاط/إزالة الحقول التي لا تفهمها (يتم كتابتها بشكل أو بآخر في مواصفات HL7 مكان ما..)