الموضوع 4.3 — قابلية التشغيل البيني ومعايير البيانات

في الصحة والرعاية، قابلية التشغيل البيني ليست لطفًا تقنيًا بل متطلب سلامة سريرية وإنصاف: عندما لا تستطيع الأنظمة مشاركة البيانات الصحيحة، بالصيغة الصحيحة، بمعنى لا لُبس فيه، عند نقطة الرعاية، يتضرر الناس ويُضخَّم عدم الإنصاف.

لماذا يهم هذا في الصحة والرعاية#

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

قابلية التشغيل البيني هي ما يُحوِّل مجموعة أنظمة مُنفصِلة إلى شيء يتصرف، من وجهة نظر المريض، كخدمة مُتصِلة. إنها السباكة تحت الرعاية المتكاملة. عندما تعمل، يستطيع طبيب في مؤسسة واحدة رؤية ما سجَّلته أخرى، ويستطيع الثقة بأنه يعني ما يعتقد أنه يعني. عندما تفشل، الفشل غالبًا صامت حتى يتضرر أحد.

هذه أيضًا مسألة إنصاف. الناس بأعقد الحاجات — كبار السن الهشون، من لديهم حالات طويلة الأمد متعددة، الناس الذين يتحركون بين خدمات — بالضبط الناس الذين بياناتهم الأكثر تجزؤًا. قابلية التشغيل البيني الضعيفة بالتالي تُؤذي الأكثر ضعفًا أشد. وهي مسألة ثقة عامة: يفترض الناس بشكل معقول أن NHS يُشارِك معلوماتهم بحكمة بالفعل، ويُخيَّبون عندما يعرفون كم لا يفعل ذلك.

أخيرًا، تحمي قابلية التشغيل البيني المال العام. الأنظمة المُملوكة التي لا تستطيع تبادل البيانات تحبس المؤسسات في عقود مُكلِفة وصعبة الاستبدال وتفرض تكاملات نقطة-لنقطة مُكلِفة. البناء لمعايير مفتوحة هو كيف تحفظ الخيارات مفتوحة، تحفظ الموردين أمناء، وتتجنب الدفع مرارًا لحل نفس المشكلة.

مفاهيم جوهرية#

قابلية التشغيل البيني هي قدرة أنظمة مختلفة على تبادل المعلومات واستخدامها. مفيد فصل طبقتين. تُقنية أو تقنية تعني أن نظامين يستطيعان تبادل رسالة وأن كل منهما يستطيع تحليل بنيتها — يصل المغلف ويمكن فتحه. تعني قابلية التشغيل البيني الدلالية أن النظام المُستقبِل يفهم ماذا يعني المحتوى بنفس الطريقة التي فهمها المُرسِل — أن رمزًا لـ"حساسية بنسلين" يُفسَّر بشكل متطابق على كلا الجانبين. قابلية تقنية بدون قابلية دلالية خطيرة: تتدفق البيانات، لكن المعنى يُفقَد أو يُشوَّه.

تُتبادَل بيانات الصحة باستخدام معايير. Health Level 7 (HL7) عائلة المعايير الأكثر استخدامًا في الرعاية الصحية. رسائل HL7 الإصدار 2 (v2) الأقدم، باستخدام نص مُفصَّل بأنابيب-وأسهم، لا يزال يدعم كمية ضخمة من رسائل المستشفى وسيفعل لسنوات. معياره الحديث، HL7 Fast Healthcare Interoperability Resources (FHIR)، يُصمِّم المعلومات السريرية كـ"موارد" مُتبادَلة عبر واجهات برمجة تطبيقات (APIs) بأسلوب ويب، الذي يجعل من الأسهل بكثير للمطورين الحديثين العمل معه.

معايير الرسالة ليست كافية؛ تحتاج أيضًا مفردات قياسية للمحتوى. SNOMED CT (Systematized Nomenclature of Medicine — Clinical Terms) هو المصطلح السريري المُكلَّف عبر رعاية NHS لتسجيل التشخيصات، الأعراض، الإجراءات، وأكثر. NHS Dictionary of medicines and devices (dm+d) هو المفردات القياسية للأدوية والأجهزة الطبية، ويدعم الوصف الإلكتروني. تُستخدَم International Classification of Diseases، النسختان 10 و11 (ICD-10 وICD-11)، التي تحافظ عليها منظمة الصحة العالمية، للتصنيف، الإحصاءات، والاسترداد بدلًا من التسجيل السريري اليومي. openEHR مواصفة مفتوحة لتهيكيل السجل الصحي نفسه من خلال "نماذج أولية" مشتركة ومحكومة سريريًا، وتستخدمها بعض المؤسسات لحفظ نماذج البيانات السريرية مستقلة عن أي مورد واحد.

فكرتان إضافيتان أساسيتان. رقم NHS هو المُعرِّف الشائع للمريض الذي يتيح ربط سجلات حول نفس الشخص بموثوقية عبر المؤسسات؛ دون مُعرِّف مشترك، المطابقة تخمين. وتنشر Integrating the Healthcare Enterprise (IHE) "ملفات تعريف" تُحدِّد بالضبط كيف تُجمَع معايير قائمة لحل مشاكل ملموسة مثل مشاركة الوثائق، بحيث يُطبِّقها موردون مختلفون بنفس الطريقة.

يدعم كل هذا خيار استراتيجي. البناء على معايير مفتوحة بـAPIs منشورة وقابلة لإعادة الاستخدام يحفظ سوقًا تنافسيًا وبياناتك قابلة للنقل. الاعتماد على واجهات مُملوكة يخلق ارتباطًا بمورد، حيث يُصبح تبديل المورد مُكلِفًا جدًا بحيث لا تستطيع فعليًا. لا شيء من ذلك يُقدِّم قيمة، مع ذلك، دون جودة بيانات: بيانات دقيقة، كاملة، في الوقت المناسب، ومُرمَّزة باستمرار هي الشرط المسبق لقابلية التشغيل البيني، لا فكرة لاحقة.

أفضل الممارسات#

1. ميِّز الدلالية من التقنية، وصمِّم لكليهما. من السهل الاحتفال بأن رسالة تتدفق الآن بين نظامين وتفويت أن الطبيب المُستقبِل لا يستطيع الاعتماد بأمان على معناها. اسأل دائمًا: هل يُفسِّر الجانب الآخر هذه الرموز، الوحدات، والنفي بالضبط كما نفعل؟ استثمر في مصطلحات مشتركة (SNOMED CT، dm+d) ومجموعات قيمة، لا صيغ رسائل فقط، لأن حساسية مُرسَلة بشكل صحيح لكن مُخطَأ فهمها أخطر من عدم وجود رسالة على الإطلاق.

2. ابنِ لمعايير مفتوحة وأعد استخدام المنصات بدلًا من إعادة الاختراع. تبنَّ المبدأ المؤيَّد على نطاق واسع: ابنِ لمعايير مفتوحة، وأعد استخدام منصات وخدمات وطنية قائمة قبل بناء خاصك. في NHS هذا يعني تفضيل APIs HL7 FHIR، استخدام رقم NHS كالمُعرِّف، والاتصال بخدمات وطنية مثل Spine، GP Connect، وسجلات رعاية مشتركة بدلًا من إنشاء روابط نقطة-لنقطة مخصصة. إعادة الاستخدام تُقلِّل التكلفة، تُوزِّع عبء الصيانة، وتعني أن بياناتك تستطيع السفر.

3. اجعل رقم NHS غير قابل للتفاوض في كل سجل ورسالة. يعتمد ربط السجلات الموثوق على مُعرِّف مشترك موثوق. تأكد أن رقم NHS مُلتقَط، مُتحقَّق منه مقابل الخدمة الديموغرافية الوطنية، ومحمول على كل سجل وواجهة ذات صلة. حيث يكون مفقودًا أو غير مُتحقَّق منه، عامل ذلك كعيب جودة بيانات يجب حله، لأن المطابقة على الاسم وتاريخ الميلاد فقط تُنتج كلًا من عدم تطابقات خطيرة وروابط مفقودة.

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

5. فضّل بنيات معمارية API-أولًا ومُترابِطة بشكل فضفاض على تكاملات مُشدَّدة. صمِّم بحيث تُكشَف القدرات من خلال APIs موثَّقة جيدًا ومُصدَرة يستطيع الآخرون استهلاكها دون تفاوض مخصص. هذا أبطأ في البداية من رابط قاعدة بيانات مباشر، لكنه ما يتيح لك استبدال مكوّن واحد دون إعادة بناء كل شيء حوله. يتوافق أيضًا مع كيف تتوقع الخدمات الوطنية والموردون الحديثون التكامل الآن، ويدعم مقاربات التسليم في الموضوع 3.5 — دورات حياة التسليم.

6. استخدم ملفات تعريف منشورة واختبار امتثال، لا تفسيرات محلية. المعايير مرنة، ويمكن لفرقتين تطبيق "نفس" مورد FHIR بشكل غير متوافق. تبنَّ دلائل تطبيق وطنية وملفات تعريف IHE تُحدِّد التفاصيل، واطلب من الموردين إظهار الامتثال مقابلها قبل الإطلاق. يُحوِّل اختبار الامتثال "ندعم FHIR" — ادعاء يعني القليل جدًا بنفسه — إلى حقيقة قابلة للتحقق وتعاقدية.

7. اكتب متطلبات قابلية التشغيل البيني والمعايير المفتوحة في الشراء والعقود. أرخص وقت لتجنب الارتباط هو قبل التوقيع. اطلب APIs مفتوحة وموثَّقة، حق استخراج بياناتك الخاصة بصيغة قياسية، الالتزام بمعايير مُسمّاة، ولا رسوم للتكاملات القياسية. اعمل مع زملاء تجاريين (انظر الموضوع 6.3 — الشراء والتجاري) بحيث تُصبح هذه معايير تقييم إلزامية، لا طموحات يُتفاوَض عليها لاحقًا.

8. احكم قابلية التشغيل البيني بالسلامة السريرية وحوكمة المعلومات في الغرفة. يُغيِّر كل تدفق بيانات جديد الخطر السريري ومعالجة المعلومات السرية. أحضر ضباط سلامة سريرية وقادة حوكمة معلومات لقرارات التصميم من البداية، لا كموافقة نهائية، بحيث تكون السجلات المشتركة آمنة وقانونية معًا. يرتبط هذا مباشرة بالموضوع 1.6 — السلامة السريرية وإدارة المخاطر والموضوع 1.7 — حوكمة المعلومات، حماية البيانات والأمن السيبراني.

أسئلة للمناقشة مع فريقك#

1. أين في مساراتنا الرعائية تخلق بيانات مفقودة أو سيئة الفهم أعظم خطر سريري اليوم؟ ينبغي أن يتبع استثمار قابلية التشغيل البيني الضرر والقيمة، لا الأناقة المعمارية. ارسم الرحلات التي يخطوها مرضاك الأعقد فعليًا وابحث عن التسليمات حيث تُفقَد المعلومات، تتأخر، أو تصل بلا معنى موثوق. اسأل الأطباء أين يعملون عمياء بشكل روتيني — التحويلات، الفجوات خارج ساعات العمل، الحد بين الصحة والرعاية الاجتماعية. ميِّز الأماكن التي لا تتدفق فيها البيانات على الإطلاق عن الأماكن التي تتدفق فيها لكن لا يمكن الوثوق بها، لأن هذه تحتاج إصلاحات مختلفة. فكّر أي الفئات السكانية الأكثر تأثرًا، لأن التجزؤ ينزع للسقوط أشد على الناس بأعقد الحاجات. تُخبرك الإجابة أين تبدأ، وتُعطيك حالة سلامة سريرية ستحمل وزنًا أكبر من أي حجة تقنية.

2. كم نحن مُعرَّضون للارتباط بمورد، وماذا سيُكلِّفنا فعليًا تبديل أنظمتنا السريرية الرئيسية؟ تكتشف كثير من المؤسسات السعر الحقيقي لنظام مُغلَق فقط عندما تحاول مغادرته. اعمل ملموسًا عبر ماذا سيتطلب استخراج بياناتك بصيغة قابلة للاستخدام وقياسية والانتقال لمورد آخر. افحص عقودك لمن يملك البيانات، أي واجهات قياسية موجودة، وما إذا كنت تُحمَّل رسومًا لتكاملات ينبغي أن تكون روتينية. حدِّد الواجهات وصيغ البيانات المُملوكة التي يجب فكها. زِن هذا مقابل انفتاح البدائل والمنصات الوطنية التي تستطيع إعادة استخدامها بدلًا. هذا ليس حول تبديل الموردين؛ إنه حول فهم نفوذك وتقليل خطر أن تُصبح خارطة طريق مورد واحد خيارك الوحيد.

3. هل بياناتنا جيدة بما يكفي للمشاركة بأمان، وكيف سنعرف؟ مشاركة بيانات ضعيفة لا تُحرِجك فقط — تُنشِر أخطاء في قرارات أطباء آخرين. اسأل ما إذا كنت تقيس فعليًا اكتمال، دقة، توقيت، واتساق ترميز البيانات التي تنوي كشفها. ناقش من يملك جودة البيانات في مؤسستك وما إذا كان لديه الوقت والتفويض لإصلاح المشاكل عند المصدر. فكّر أي نسبة من السجلات تحمل رقم NHS مُتحقَّقًا منه وكم من المعلومات السريرية المهمة لا تزال تجلس في نص حر بدلًا من حقول مُرمَّزة. فكّر كيف ستكتشف خطأ ترميز منهجي قبل أن يصل سجل رعاية مشترك. إذا لم تستطع الإجابة على هذه الأسئلة بدليل، عامل ذلك كنتيجة بحد ذاتها، ومَوِّل عمل جودة البيانات قبل توسيع الأنبوب.

4. عندما يقول مورد "ندعم FHIR"، كيف سنُتحقَّق منه فعليًا قبل الإطلاق؟ تسمية معيار ادعاء تسويقي حتى يُختبَر مقابل دليل تطبيق محدد. ناقش ما إذا كان لمؤسستك قدرة اختبار امتثال خاصة بها، أو ما إذا كنت تأخذ فقط بكلمة الموردين. يمكن لنظامين أن يكونا "مُوافِقين لFHIR" ولا يزالان غير قادرين على تبادل رسالة قابلة للاستخدام، لأن المعيار مرن عمدًا والمعنى يعيش في ملفات التعريف ومجموعات القيمة التي تُحدِّده. اسأل أي دلائل تطبيق وطنية وملفات تعريف IHE تنطبق على الواجهة قيد السؤال، ومن على جانبك كفؤ لقراءتها. فكّر ما إذا كان الامتثال مكتوبًا في العقد كشرط للاتصال، أو مُكتشَف بألم أثناء التكامل. إجابة أمينة تُسمّي ملف التعريف المحدد الذي ستختبر مقابله، الشخص أو الوظيفة التي ستُشغِّل الاختبار، والنقطة في الجدول الزمني حيث يُرفَض مورد فاشل بدلًا من تجاوزه.

5. من يملك المعايير، المصطلحات، والامتثال عبر مؤسستنا، وهل لديه التفويض لقول لا؟ تتحلل قابلية التشغيل البيني دون إشراف: تنجرف مجموعات القيمة، تتباعد الدلائل المحلية، ويخترع كل مشروع جديد بهدوء تفسيره الخاص. اسأل ما إذا كانت هناك وظيفة مُسمّاة مسؤولة عن المعايير، مجموعات فرعية SNOMED CT وdm+d، والامتثال، أو ما إذا كانت هذه المعرفة تجلس في رؤوس أفراد قليلين. فكّر في التوتر بين الاتساق المركزي وسرعة التسليم المحلي — الفرق تحت ضغط ستبني أسرع شيء إلا إذا كانت لوظيفة معايير سلطة حقيقية لطلب إعادة الاستخدام. ناقش كيف تُموَّل صيانة المصطلحات، بالنظر إلى أنها غير برّاقة، مستمرة، وتُفيد كل شخص بدلًا من مشروع واحد. انظر كيف تحفظ التطبيقات مُتَّسِقة مع تطور FHIR، SNOMED CT، والدلائل الوطنية، بدلًا من التجمد عند الإصدار الذي تبنّيته أولًا. إجابة أمينة تُحدِّد المالك المُساءَل، تمويله، ومثالًا حديثًا حيث طبَّق معيارًا أو فشل.

6. هل الناس الذين نُوصِّل سجلاتهم مُخبَرون وراضون بكيف تتدفق بياناتهم؟ قابلية التشغيل البيني ليست فقط مسألة تقنية وسريرية بل سؤال ثقة عامة وأساس قانوني. يفترض الناس بشكل معقول أن NHS يُشارِك معلوماتهم بحكمة بالفعل، ويُخيَّبون كلًا حين لا يفعل وحين يفعل بطرق لم يتوقعوها. ناقش ما إذا كان المرضى يفهمون أي مؤسسات تستطيع رؤية سجلهم المشترك، كيف يُحتَرَم الانسحاب الوطني من البيانات أو نموذج موافقة محلي عبر التدفق، وكيف يُسجَّل الوصول ويكون قابلًا للتدقيق. فكّر في بُعد الإنصاف: الناس الذين بياناتهم الأكثر تجزؤًا — من لديهم حاجات مُعقَّدة — هم أيضًا الأقل قدرة على التنقل في الانسحابات وإشعارات المعلومات. أحضر حوكمة المعلومات، وحيث ذو صلة، المرضى أو ممثليهم في التصميم بدلًا من معاملة الموافقة كصندوق يُوضَع عليه علامة في النهاية. إجابة أمينة تستطيع وصف الأساس القانوني لكل تدفق، كيف سيكتشف شخص من رأى سجله، وكيف تُحتَرَم خياراته من البداية للنهاية.

في الممارسة: مثال من الصحة والرعاية#

يُطلِق نظام رعاية متكامل في شمال إنجلترا مهمة إعطاء الأطباء عرضًا واحدًا للأدوية المشتركة عبر الممارسة العامة، المستشفى، والصيدلية المجتمعية، بعد أن وجدت مراجعة حادث جدي أن مريضًا وُصِف له دواءان متفاعلان من فرق لم تستطع رؤية سجلات بعضها.

الإغراء هو شراء "لوحة معلومات أدوية" من مورد واحد وربطها مباشرة بقاعدة بيانات كل نظام. يُقاوِم قائد قابلية التشغيل البيني هذا. بدلًا من ذلك، يتبنى البرنامج نهج بناء-لمعايير-مفتوحة. تكشف كل نظام مصدر بيانات الدواء كموارد HL7 FHIR؛ يُرمَّز كل دواء باستخدام dm+d بحيث يعني "نفس الدواء" نفس الشيء في كل مكان؛ ويُرمَّز كل سجل برقم NHS مُتحقَّق منه بحيث تلتصق الأدوية الصحيحة بالشخص الصحيح. تُستخلَص بيانات طبيب الأسرة من خلال GP Connect بدلًا من تدفق مخصص، تُعيد استخدام قدرة وطنية بدلًا من اختراع محلية.

يُثبِت تصنيف البيانات المبكر قيمته فورًا. سجَّل نظام ممارسة واحدة أدوية معينة في نص حر بدلًا من مدخلات dm+d مُرمَّزة، مما يعني أنها كانت ستكون غير مرئية لأي فحص تفاعل آلي. يُصلَح هذا عند المصدر قبل الإطلاق. يجد الفريق أيضًا مجموعة سجلات بأرقام NHS غير مُتحقَّقة ويُوجِّهها من خلال الخدمة الديموغرافية الوطنية للمطابقة.

ضابط السلامة السريرية وقائد حوكمة المعلومات جزء من مجموعة التصميم طوال الوقت. معًا يُعرِّفان بالضبط أي بيانات مُشارَكة، مع من، تحت أي أساس قانوني، وكيف يُسجَّل وصول طبيب — مخاوف الموضوع 1.7 — حوكمة المعلومات، حماية البيانات والأمن السيبراني. يجب أن يمر الموردون باختبار امتثال مقابل دليل تطبيق FHIR الوطني قبل الاتصال. بعد اثني عشر شهرًا، عرض الدواء المُتصِل مباشر، اُكتُشِف تفاعل كان سيُفوَّت سابقًا، و— لأن كل شيء بُني على واجهات مفتوحة — حالة استخدام ثانية، معلومات حساسية مشتركة، تُعيد استخدام معظم نفس السباكة بجزء من التكلفة الأصلية.

عدسات قطاعية#

شركة ناشئة#

تحيا أو تموت شركة صحة رقمية ناشئة بكم بسهولة تُدرِج نفسها في أنظمة قائمة، لذا عامل قابلية التشغيل البيني كميزة جوهرية، لا عمل امتثال. بناء APIs FHIR واستخدام SNOMED CT وdm+d من البداية يجعلك أسهل بكثير للشراء والتكامل، ويُشير بالنضج لمشترين NHS الحذرين. قاوم إغراء اختراع نموذج بياناتك الخاص عندما يوجد معيار؛ ينبغي أن يكون تمييزك منتجك، لا صيغة مُملوكة تُصبح التزامًا. الحصول على معالجة رقم NHS وحوكمة المعلومات بشكل صحيح مبكرًا هو ما يتيح لك الانتقال من تجربة تجريبية للشراء. صمِّم بحيث يستطيع عميل، مبدئيًا، استخراج بياناته والمغادرة — متناقضًا، ذلك الانفتاح هو ما يكسب الثقة التي تحفظهم.

شركة صغيرة#

يحمل مقدم خدمة صغير راسخ — عيادة طبيب عام، صيدلية مجتمعية، دار رعاية، أو عيادة أحادية الموقع — نفس واجبات مشاركة البيانات بأمان كأكبر مؤسسة ائتمانية، لكن بجزء من القدرة التقنية. قابلية التشغيل البيني هنا أساسًا انضباط شراء وتهيئة بدلًا من هندسي: اختر أنظمة تتحدث FHIR بالفعل، اتصل بخدمات وطنية مثل GP Connect وSpine، ورمِّز بSNOMED CT وdm+d جاهزين، بحيث تُورِّث معايير بدلًا من بنائها. اجعل التقاط رقم NHS المُتحقَّق منه جزءًا من الممارسة اليومية، لأنه دون فريق تكامل لتسوية عدم التطابقات لاحقًا، الحصول على المُعرِّف بشكل صحيح عند نقطة التسجيل ضمانك الأرخص. اعتمد على برامج سجل رعاية مشترك والبنية التحتية المشتركة لنظام رعايتك المتكاملة بدلًا من تكليف روابط مخصصة لا تستطيع صيانتها. عندما توقِّع أو تُجدِّد عقد نظام، أصرّ على حقوق استخراج بيانات وواجهات مفتوحة بمصطلحات بسيطة، لأن مؤسسة صغيرة تشعر بالارتباط بمورد أشد وأقل نفوذًا للهروب منه بعد الحقيقة.

مؤسسة كبيرة#

يحمل مقدم خدمة أو مورد كبير عادة عقودًا من الإرث: واجهات HL7 v2، أنظمة سجل إلكتروني متعددة، ومحركات تكامل تحفظ كل شيء معًا. الاستراتيجية الواقعية ليست انتزاع كل شيء بل وضع طبقة API-أولًا ومُستنَدة إلى معايير أمام الأصول، تُهجِّر تدفقات لFHIR تدريجيًا بينما تحفظ v2 يعمل حيث يجب. احترس بشدة من الارتباط عند كل تجديد، وأصرّ على اختبار امتثال بحيث "مُوافِق للمعايير" مُتحقَّق منه بدلًا من مُدَّعى. أسِّس وظيفة معايير وامتثال داخلية بحيث لا تخترع مشاريع فردية كل منها تفسيرها الخاص. هذا يرتبط بشدة بكيف تُدير منصات تشغيل أساسية في الموضوع 5.4 — تخطيط موارد المؤسسة (ERP)، حيث ينطبق نفس انضباط إعادة الاستخدام والواجهة المفتوحة.

حكومة#

تضع الجهات الوطنية والإقليمية قواعد السوق، لذا تتردد خياراتها حول المعايير عبر كل مؤسسة. أكثر الأشياء قيمة التي تستطيع الحكومة فعلها هي تفويض معايير مفتوحة، نشر دلائل تطبيق ومتطلبات امتثال واضحة، وتقديم منصات وطنية قابلة لإعادة الاستخدام — Spine، GP Connect، أطر سجل رعاية مشترك، خدمة رقم NHS — بحيث تبني المؤسسات المحلية مرة واحدة وتُعيد الاستخدام. الاتساق يهم أكثر من الكمال: معيار جيد بما يكفي ومُطبَّق بحزم يتفوق على واحد نظريًا أفضل يُطبِّقه كل شخص بشكل مختلف. يجب أن تُموِّل الحكومة أيضًا العمل غير البرّاق لصيانة المصطلحات وتحسين جودة البيانات، لأن هذه أخيار عامة لن تُموِّلها أي مؤسسة واحدة بمفردها. هذا دور الإشراف يرتبط بالموضوع 9.1 — العمل مع الحكومات المحلية والوطنية وكيف يتعاون الشركاء في الموضوع 9.0 — التعاون مع المؤسسات الشريكة.

أنماط فشل شائعة#

• خلط الاتصال التقني بالفهم الدلالي. إعلان النصر عندما تتدفق رسالة، دون التأكيد أن كلا الجانبين يُفسِّران رموزها، وحداتها، ونفيها بشكل متطابق. النتيجة بيانات تبدو مُتكامِلة لكنها تُقرَأ خطأً بهدوء.
• مشاركة بيانات ضعيفة أسرع. توسيع الأنبوب قبل إصلاح جودة البيانات، بحيث تُنتشِر أخطاء الترميز، النص الحر، وأرقام NHS المفقودة في قرارات أطباء آخرين وكل تحليل في المصب.
• "ندعم FHIR" كادعاء فارغ. قبول تسمية معيار دون اختبار امتثال مقابل دليل تطبيق محدد، بحيث لا يزال نظامان "مُوافِقان" غير قادرين على التحدث لبعضهما.
• تكاملات مخصصة نقطة-لنقطة. بناء روابط مباشرة بين كل زوج من الأنظمة، تُنتج شبكة هشة تُصبح أصعب وأكثر تكلفة للصيانة أضعافًا مع نموها.
• الارتباط افتراضيًا. توقيع عقود بواجهات مُملوكة ولا حقوق استخراج بيانات، تكتشف تكلفة الفخ فقط عند محاولة تغيير المورد.
• معاملة الحوكمة كبوابة نهائية. إحضار السلامة السريرية وحوكمة المعلومات فقط للموافقة، بحيث تظهر المشاكل متأخرة ومُكلِفة، أو تُتجاوَز تحت ضغط التسليم.
• معايير بلا إشراف. تبني مصطلحات وملفات تعريف لكن تمويل لا أحد لصيانة مجموعات القيمة، مراقبة الامتثال، أو حفظ التطبيقات مُتَّسِقة مع تطور المعايير.

نموذج النضج#

قائمة التحقق#

• كل سجل وواجهة ذات صلة تحمل رقم NHS مُتحقَّقًا منه، بعملية لحل المفقودة أو غير المُتطابِقة.
• الواجهات الجديدة تستخدم HL7 FHIR ودلائل تطبيق وطنية مُسمّاة، مع الاحتفاظ بHL7 v2 فقط حيث الهجرة غير مُبرَّرة بعد.
• المحتوى السريري مُرمَّز باستخدام SNOMED CT، والأدوية باستخدام dm+d، مقابل مجموعات قيمة مُتَّفَق عليها.
• جودة البيانات لأي شيء تنوي مشاركته مُصنَّفة، مُقاسة، مملوكة، ومُحسَّنة عند المصدر قبل توسيع الأنبوب.
• يجب أن يمر الموردون باختبار امتثال مقابل ملف تعريف محدد قبل الاتصال — "يدعم FHIR" لا يُقبَل أبدًا بمفرده.
• المنصات الوطنية (Spine، GP Connect، سجلات رعاية مشتركة) مُعاد استخدامها قبل بناء أي تكامل مخصص.
• تُلزِم العقود APIs مفتوحة وموثَّقة، حقوق استخراج بيانات بصيغة قياسية، ولا رسوم للتكاملات القياسية.
• قادة السلامة السريرية وحوكمة المعلومات في مجموعة التصميم من البداية، لا عند الموافقة فقط.
• البنية المعمارية API-أولًا ومُترابِطة بشكل فضفاض، بحيث يمكن استبدال مكوّن دون إعادة بناء كل شيء حوله.
• وظيفة مُسمّاة تملك المعايير، الامتثال، وصيانة المصطلحات عبر المؤسسة.

المصادر الرئيسية#

• NHS England — interoperability standards, the Spine, GP Connect, and shared care record programmes.
• HL7 International — the FHIR standard and HL7 v2 specifications.
• SNOMED International — SNOMED CT terminology and implementation guidance.
• NHS Business Services Authority — the Dictionary of medicines and devices (dm+d).
• Integrating the Healthcare Enterprise (IHE) — interoperability profiles.
• openEHR International — open specifications for structuring the health record.
• World Health Organization — the International Classification of Diseases (ICD-10 and ICD-11).

المراجع#

1. Interoperability — ويكيبيديا — https://en.wikipedia.org/wiki/Interoperability
2. Semantic interoperability — ويكيبيديا — https://en.wikipedia.org/wiki/Semantic_interoperability
3. Health Level 7 — ويكيبيديا — https://en.wikipedia.org/wiki/Health_Level_7
4. Fast Healthcare Interoperability Resources — ويكيبيديا — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
5. SNOMED CT — ويكيبيديا — https://en.wikipedia.org/wiki/SNOMED_CT
6. ICD-11 — ويكيبيديا — https://en.wikipedia.org/wiki/ICD-11
7. ICD-10 — ويكيبيديا — https://en.wikipedia.org/wiki/ICD-10
8. openEHR — ويكيبيديا — https://en.wikipedia.org/wiki/OpenEHR
9. NHS number — ويكيبيديا — https://en.wikipedia.org/wiki/NHS_number
10. Integrating the Healthcare Enterprise — ويكيبيديا — https://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise
11. Open standard — ويكيبيديا — https://en.wikipedia.org/wiki/Open_standard
12. Vendor lock-in — ويكيبيديا — https://en.wikipedia.org/wiki/Vendor_lock-in
13. API — ويكيبيديا — https://en.wikipedia.org/wiki/API
14. Data quality — ويكيبيديا — https://en.wikipedia.org/wiki/Data_quality
15. FHIR standard — HL7 International — https://www.hl7.org/fhir/
16. SNOMED CT — SNOMED International — https://www.snomed.org/
17. Dictionary of medicines and devices (dm+d) — NHS Business Services Authority — https://www.nhsbsa.nhs.uk/pharmacies-gp-practices-and-appliance-contractors/dictionary-medicines-and-devices-dmd
18. GP Connect — NHS England Digital — https://digital.nhs.uk/services/gp-connect
19. Spine — NHS England Digital — https://digital.nhs.uk/services/spine
20. International Classification of Diseases (ICD) — World Health Organization — https://www.who.int/standards/classifications/classification-of-diseases