ملخص
- وضعت خدمة إسعاف لندن نموذج تشغيل غير مكتمل قيد الاستخدام الحيوي الكامل في 26 أكتوبر 1992. ووجد التحقيق برمجيات غير منتهية وغير مختبرة بشكل كافٍ، ومرونة غير مختبرة تحت الحمل الكامل وخطط بديلة غير مختبرة، وبيانات حالة وموقع غير موثوقة، وقيود في الاتصالات، وتدريب غير متسق، وضعف في ملكية المستخدم، وتغيير في غرفة التحكم أزال مسارات التصحيح الورقية والبشرية المألوفة.
- يجب التمييز بين أحداث 26 و27 أكتوبر والتعطل الذي حدث في 4 نوفمبر. وفقًا لرواية التحقيق، لم يفشل الكمبيوتر بالمعنى التقني الضيق في اليومين الأولين؛ بل تسببت عيوب تفاعلية في التصميم والتشغيل في ظهور أعراض فشل النظام وتأخير غير مقبول. في 4 نوفمبر، تسبب خطأ برمجي بسيط في تعطل، ولم يحافظ التبديل التلقائي غير المختبر بشكل كافٍ على الخدمة.
- تتبع المساءلة السيطرة العملية على أدلة الجاهزية. كان على الموردين تقديم تنفيذ صادق وأدلة جودة؛ وسيطرت إدارة LAS على المتطلبات والتكامل والتدريب والخطط البديلة والتحول؛ وسيطر المجلس وهيئة الصحة الإقليمية على التدقيق؛ وتحمل الوزراء الإشراف العام. كانت الطواقم ومستخدمو غرفة التحكم مصادر أساسية للأدلة التشغيلية، وليس تفسيرًا مناسبًا لنظام افترض عدم الكمال المتوقع.
- لم يرفض التحقيق الأتمتة. وخلص إلى أن LAS والجمهور يمكن أن يستفيدوا من CAD، وأوصى بمواصلة التخطيط واقترح مسارًا تدريجيًا. تشير الأبحاث اللاحقة حول تحول الخدمة بالمثل إلى مشاركة المستخدمين، والتوقيت الواقعي، والنماذج الأولية، والاختبار الشامل، والتنفيذ البسيط على مراحل، والثقة في البنية التحتية والثقة كآليات إصلاح.
الإرسال في حالات الطوارئ هو مشكلة تقدير الحالة
يجب على نظام الإرسال في حالات الطوارئ أن يعرف أكثر من مجرد ما إذا كانت عملية البرنامج قيد التشغيل. يجب أن يعرف أنه تم فهم المكالمة، وأن موقع الحادث قابل للاستخدام، وأن سيارة إسعاف معينة متاحة، وأن موقعها المسجل موثوق، وأن رسالة التعبئة وصلت إلى الطاقم، وأن تحديث الحالة التالي للطاقم عاد إلى جهاز التحكم. يجب أن يحافظ على تلك الصورة التشغيلية متماسكة بينما يتغير الطلب والجغرافيا والظروف البشرية. لا يمكن لإقناع ذي حمل متواضع أن يثبت أن الصورة ستبقى صحيحة أثناء نوبة عمل صعبة.
وصف تحقيق خدمة إسعاف لندن أربع وظائف قيادية أساسية: استقبال المكالمات والتحقق منها، وتحديد المورد المناسب، وتوصيل التعبئة، وإدارة موقع موارد الإسعاف. ربط نظام الإرسال بمساعدة الحاسوب المقصود هذه الوظائف بدليل المواقع، والخرائط، ومحطات البيانات المتنقلة، وتحديد مواقع المركبات تلقائيًا، والاتصالات اللاسلكية، ومعلومات الإدارة. يمكن أن يبدو كل مكون محليًا معقولاً بينما كانت الصورة المجمعة خاطئة. قد يكون تحديد الموقع قديمًا، وقد تكون المركبة قد غيرت حالتها، وقد تفشل رسالة بيانات، أو قد تعود مكالمة إلى قائمة الانتظار دون أن يرى المراقب السبب.
لهذا السبب لا يوصف فشل عام 1992 بشكل كافٍ على أنه تطبيق سيئ. كان CAD يصبح سطح التحكم في الخدمة: المكان الذي تُحول فيه التقارير غير الكاملة من المتصلين والطواقم وأجهزة الراديو وقواعد البيانات إلى قرارات حول سيارات إسعاف حقيقية. لذلك اعتمدت جاهزيته على مؤسسة الإرسال بأكملها. كانت جودة البرمجيات مهمة، ولكن كذلك سعة الاتصالات، وتخطيط الغرفة، والتوظيف، والتدريب، وممارسات العمل، ومعالجة الاستثناءات، وسلطة إيقاف الانتقال عندما لا تتفق هذه العناصر.
يحمي هذا التأطير القضية من استنتاج مناهض للأتمتة. كانت عملية الإرسال اليدوي بها قيود خطيرة. كانت نماذج الحوادث الورقية تنتقل فعليًا حول غرفة التحكم؛ اعتمد الموزعون على الخرائط والتقارير اللاسلكية وسجلات المركبات المحفوظة؛ يمكن أن تصطف القنوات الصوتية؛ اعتمد تحديد المكالمات المكررة على الذاكرة والحكم. وجد التحقيق دعمًا واسعًا لاستخدام التكنولوجيا لتحسين الخدمة. لم يكن الفشل هو طموح الأتمتة. بل كان السماح للأتمتة بممارسة السلطة الحية قبل أن تمتلك المؤسسة أدلة مقنعة على أن حالتها التشغيلية وأفرادها ومسارات التعافي كانت جاهزة.
حاول المشروع عبور فجوة الأتمتة في خطوة واحدة
كانت LAS قد حاولت بالفعل حوسبة القيادة والتحكم. تم التخلي عن مشروع سابق بدأ في الثمانينيات في عام 1990 بعد أن أظهر اختبار الحمل أنه لا يمكنه تلبية الطلب المتوقع. بدأ جهد الاستبدال بإعداد مواصفات متطلبات النظام الجديد من خريف 1990 إلى فبراير 1991. تبعتها العقود في وقت لاحق من عام 1991، وكان التنفيذ الكامل مقررًا في الأصل لشهر يناير 1992. كان ينبغي للتاريخ أن يجعل حمل النظام والمتطلبات المتغيرة ومخاطر التكامل أسئلة قبول مركزية.
كان المفهوم الجديد أكثر طموحًا من مجرد أداة استقبال مكالمات محوسبة. سعت LAS إلى نظام مؤتمت إلى حد كبير حيث تتلقى غالبية المكالمات اقتراحًا مولّدًا بالكمبيوتر لسيارة الإسعاف الأكثر ملاءمة. فقط الحالات المعقدة تتطلب موزعًا متخصصًا. ستغذي بيانات تحديد مواقع المركبات تلقائيًا والبيانات المتنقلة صورة الموارد؛ يمكن لمستقبلي المكالمات تسليم الحادث عبر التخصيص؛ سيعمل الإرسال في النهاية عبر لندن بدلاً من النموذج الانقسامي المألوف. وصف التحقيق الانتقال المقصود من عملية يدوية بالكامل إلى أتمتة كاملة في مرحلة واحدة بأنه قفزة عالية المخاطر.
كما كان لأعمال المتطلبات نقاط ضعف في الملكية والحدود. كانت المواصفات تفصيلية وتوجيهية، ومع ذلك كان هناك القليل من المشاركة المبكرة من طواقم الإسعاف التي سيتغير عملها. لم يتم تعريف الواجهات مع الاتصالات الحالية وأنظمة LAS الأخرى بشكل كامل، ولم يجد التحقيق أي دليل على اعتماد رسمي لمواصفات المتطلبات. لا يزال بإمكان الوثيقة الدقيقة أن تكون غير مكتملة إذا لم يقبلها الأشخاص والواجهات والافتراضات التشغيلية التي تحدد النجاح.
المتطلبات في خدمة حرجة للسلامة لا تنتهي عندما يتم سرد الوظائف. يجب أن تحدد كيف يتصرف النظام عندما تفشل مركبة في الإبلاغ، عندما يكون التغطية اللاسلكية ضعيفة، عندما يبلغ اثنان من المتصلين عن حادث واحد بشكل مختلف، عندما يستخدم طاقم مركبة أخرى، عندما يتم قفل محطة عمل، أو عندما تتجاوز قائمة الانتظار المساحة المرئية للشاشة. يجب أن تذكر أيضًا الدليل الذي يسمح لكل خطوة أتمتة باستبدال تحكم بشري موجود. حددت LAS سير عمل مثاليًا قويًا لكنها لم تربط سير العمل هذا بالظروف غير المثالية التي سيتعين عليه العمل فيها.
البيانات شبه المثالية لم تكن افتراض تشغيل آمن
حدد التحقيق مرارًا اعتماد النظام على معلومات شبه مثالية عن موقع المركبات وحالتها. إذا كان النظام يعرف مكان كل سيارة إسعاف وما يفعله كل طاقم، يمكن أن تكون الاقتراحات الآلية مفيدة. إذا لم يكن كذلك، يمكنه التوصية بثقة بمورد بينما يوجد مورد أقرب أو أكثر ملاءمة خارج صورته المسجلة. لم يكن بحاجة إلى أن يكون روتين التخصيص معطلاً رياضياً ليكون الجواب التشغيلي خاطئًا.
كانت هناك طرق عادية عديدة للوصول إلى حالة غير كاملة. قد يخطئ الطاقم في زر الحالة أو يضغط عليه في وقت غير مناسب تحت ضغط الحادث. قد يواجه الإرسال بقعة سوداء لاسلكية أو قناة مزدحمة. قد تظهر محطة متنقلة تبادلًا ناجحًا بينما تحمل شاشة التحكم حالة أخرى. قد تكون إشارات النداء مفقودة أو مبادلة. قد يستخدم طاقم مركبة غير تلك المسجلة. قد تكون معدات الموقع والتركيب غير موثوقة. ربما استخدم بعض الموظفين النظام بشكل غير صحيح أو متعمد، لكن التحقيق لم يجد دليلاً مباشرًا يدعم إسناد الإدارة الواسع لمشاكل CAD إلى سوء الاستخدام المتعمد، وتعامل مع هذا السلوك، على الأكثر، كعامل واحد من بين عوامل كثيرة.
بدلاً من ذلك، ضاعف النقص العمل. أنتجت الحالة غير الصحيحة مقترحات سيئة ورسائل استثناء. ولدت الاستثناءات غير المحلولة المزيد من الاستثناءات. يمكن للمكالمات المغطاة العودة إلى قائمة الانتباه عند عدم اكتمال دورة الحالة المتوقعة. مع نمو القوائم، انتقلت الرسائل خارج العرض، وتباطأت المعالجة، وأصبح لدى الموظفين وقت أقل لتصحيح الحالة التي تسببت في الرسائل. دفعت التأخيرات أفراد الجمهور إلى الاتصال مرة أخرى، مما أضاف عملاً في مقدمة النظام. لذلك كان العبء التشغيلي داخلي المنشأ: استجابة النظام للبيانات غير الكاملة خلقت طلبًا أكبر على نفس الأشخاص والقنوات المقيدة.
آلية التغذية الراجعة هذه هي جوهر القضية. لم تكن جودة البيانات مقياساً للنظافة يمكن إصلاحه بعد الإطلاق. لقد حكمت على أي سيارة إسعاف يمكن للخدمة إرسالها. لم تكن سعة الاستثناءات تفضيلاً بسيطاً لواجهة المستخدم. لقد حددت ما إذا كان بإمكان المشغلين استعادة الحقيقة بشكل أسرع من تراكم الأخطاء. عنت حقيقة المتطلبات إظهار أن الخدمة يمكنها البقاء على قيد الحياة بمعدلات واقعية من المعلومات المفقودة والمتأخرة والمتضاربة، وليس توثيق أن الإدخال المثالي سينتج إخراجًا مثاليًا.
جعلت المشتريات الوقت والسعر جزءًا من التصميم التقني
اتبعت المشتريات التعليمات المالية الدائمة لهيئة الصحة الإقليمية، بما في ذلك المناقصات المفتوحة وافتراض تفضيل أقل عطاء ما لم تكن هناك أسباب وجيهة على خلاف ذلك. لم يجد التحقيق أن القواعد الرسمية قد تم تجاهلها ببساطة. ووجد أن القواعد قدمت القليل من التوجيه النوعي لاقتناء تكنولوجيا معلومات رئيسي، مع التركيز بشكل أكبر على السعر بدلاً مما إذا كان المورد والتصميم المتكامل يمكنهما القيام بالعمل بأمان.
أبدت خمس وثلاثون شركة اهتمامًا في البداية، وقدمت سبعة عشر مقترحات لجزء أو كل النظام. أثار العديد من الموردين المحتملين مخاوف بشأن الجدول الزمني المخطط للتنفيذ الكامل. قيل لهم إنه غير قابل للتفاوض. على الرغم من أن بروتوكول التقييم صنف القدرة الوظيفية والإنتاجية وسهولة الاستخدام والمرونة، وجد التحقيق أن عدم القدرة على تلبية المتطلبات الكاملة أو الموعد النهائي أزال العطاء فعليًا. لذلك عمل الجدول الزمني كمتطلب تقني من الدرجة الأولى: التصميمات التي اعترفت بالحاجة إلى إثبات أطول أو مراحل كانت في وضع غير مؤات.
كان المورد الرئيسي صغيرًا وتولى مشروعًا أكبر من عمله السابق. ومع ذلك، خلص التحقيق أيضًا إلى أنه، في ظل القيود الزمنية المفروضة واتساع المتطلبات، لم يكن بإمكان أي شركة برمجيات تقديم حل عملي. هذا الاستنتاج يمنع القصة الملائمة لمورد وحيد غير فعال. كان لدى الموردين الآخرين مكونات متأخرة ومشاكل تقنية؛ امتلكت LAS المفهوم الطموح والموعد النهائي وبيئة التكامل والخدمة الحية؛ شكلت قواعد المشتريات الإقليمية الاختيار؛ وكان على قيادة المشروع أن تقرر ما إذا كانت الأدلة المقدمة كافية.
كما ترك العقد مسؤولية إدارة المشروع غامضة. توقعت LAS من المورد الرئيسي إدارة التكامل بأكمله، لكن العقد لم يعين هذا الدور بوضوح، وكافح المورد لإدارة مساهمته الخاصة. تولى موظفو LAS المزيد من التحكم بشكل افتراضي. في نظام سلامة متعدد الموردين، يعتبر المُدمج الغامض عيبًا تشغيليًا. يجب أن يمتلك شخص ما السلوك الشامل عبر برمجيات CAD والأجهزة والواجهات اللاسلكية وخدمات الموقع والمحطات المتنقلة. لا يمكن للمشتريات ببساطة شراء المكونات والأمل في ظهور المساءلة عند التقاء خطوطها.
حوّلت إدارة المشروع الضغط إلى تأكيد متفائل
اختارت LAS طريقة إدارة المشروع PRINCE، لكن لا الخدمة ولا الموردون لديهم خبرة كبيرة في تطبيقها. لم يجد التحقيق أي لجنة تنفيذية لتكنولوجيا المعلومات منظمة بشكل صحيح، أو مجلس مشروع، أو فريق إدارة مشروع، أو فريق ضمان من النوع الذي تتصوره الطريقة. لم يكن هناك مشاركون متفرغون من LAS في مرحلة مبكرة، ولم تسمح خطة المشروع بأي مجال للمراجعة والتنقيح، ولم يتم تحويل المخاوف المسجلة في الاجتماعات بشكل موثوق إلى قرارات أو أدلة مرفوعة.
اعتمد الإبلاغ عن المشروع غالبًا على تأكيدات متفائلة. أبلغ الموردون عن التقدم؛ طمأن المدراء التنفيذيون مجلس LAS وهيئة الصحة الإقليمية في جنوب غرب التايمز؛ وُصفت المشاكل المعروفة بأنها قيد التصحيح. دعا مراجعة داخلية في مارس 1992 إلى اختبار حجم الاتصالات، واستراتيجية تنفيذ موقعة، وتغييرات برمجية خاضعة للرقابة، ومراجعة للتدريب. لم يتم تقديمها إلى المجلس كما طلب المجلس. قال التقرير اللاحق للمدير التنفيذي إنه لا يوجد دليل على أن البرنامج الكامل لن يثبت موثوقيته. أجاب التحقيق بمبدأ سلامة دائم: غياب دليل عدم الموثوقية ليس تأكيدًا إيجابيًا على أن النظام الحيوي للمهمة سيؤدي.
أضعف التحكم في التغيير قاعدة الأدلة بشكل أكبر. أجرى المورد أحيانًا تغييرات برمجية مطلوبة خارج عملية تقرير مشكلة المشروع الرسمية. لذلك يمكن أن يتغير الكود المختبر سابقًا دون علم مجموعة المشروع الكاملة، ويمكن أن تدخل عيوب جديدة. بحلول 26 أكتوبر، تم رفع 1,513 تقرير مشكلة وبقي 81 مفتوحًا. كان اثنان منها في فئة الخدمة للتدهور الشديد الذي يمنع التشغيل في البيئة الحقيقية، وأربعة وأربعين في فئة مرتبطة بخدمة أسوأ للمرضى. تم المضي قدمًا في النشر الكامل بينما كان تصنيف المشكلات الخاص بـ LAS لا يزال يسجل أعطالاً تشغيلية خطيرة.
رأى المجلس وهيئة الصحة الإقليمية صعوبة مستمرة، لكن لم يطلب أي منهما المراجعة التقنية المستقلة المتعمقة التي يبررها النمط. أصبحت الحوكمة على مسافة ذراع استلامًا سلبيًا لثقة الإدارة. لا يحتاج المجلس إلى تصحيح أخطاء البرمجيات، لكن يجب أن يطلب دليل جاهزية مقروء: نتائج اختبار متكامل، عيوب عالية الخطورة غير محلولة، إتمام التدريب، تجربة الخطط البديلة، سعة الاتصالات، قبول المستخدم، وقرار موقع يحدد من يمكنه أن يقول لا. بدون تلك المواد، يصبح الإشراف سلسلة لنقل التفاؤل إلى الأعلى بدلاً من حقيقة المخاطر.
لم يختبر الاختبار خدمة الإرسال الكاملة مطلقًا
تمت مناقشة الاختبارات الوظيفية واختبارات الحمل طوال المشروع. كانت المحاولات الأولى في يناير 1992 غير حاسمة لأن البرمجيات كانت غير مكتملة ولم تكن جميع المكونات متاحة. في الأشهر اللاحقة، تم اختبار أجزاء من CAD وتتبع الموقع والاتصالات، لكن التحقيق وجد أن النظام المتكامل الكامل لم يتم اختباره ككل أبدًا. التغييرات المستمرة في البرمجيات والبيانات المتنقلة وتقنية الموقع والواجهة اللاسلكية عنت أنه لم يكن هناك خط أساس مستقر يمكن الوثوق به لتجربة الخدمة الكاملة.
لم تقتصر الثغرات على تغطية الكود. مرونة الأجهزة تحت الحمل الكامل غير مثبتة. لم يتم اختبار التبديل إلى خادم ملفات ثانٍ بشكل كافٍ. لم يتم حساب حجم الاتصالات بشكل منهجي قبل التنفيذ. لم يتم تمثيل عواقب حالة المركبة المتأخرة أو المفقودة بمعدلات واقعية. لم تقم نصوص الاختبار بحقن التناقضات في الموقع وإخفاقات الاتصالات المعروفة بحدوثها في عمليات لندن الحقيقية. لذلك تم اختبار النظام مقابل عالم أنظف من العالم الذي طُلب منه التحكم فيه.
الحمل الواقعي هو أكثر من مجرد عدد مستهدف من المكالمات في الساعة. يشمل شكل الطلب والعمل الناتج عن الخطأ: تغييرات الورديات التي تجعل العديد من الطواقم تسجل الدخول، وازدحام الراديو، والمكالمات المكررة، والمتصلون الذين يطلبون تقدير وصول، ومركبات ذات حالة قديمة، ومحطات طرفية تعيد المحاولة، ومشغلون يصححون التخصيصات، واستثناءات تلد المزيد من الاستثناءات. يشمل العبء المعرفي للقوائم التي تتحرك خارج الشاشة والتأخير الناتج عن توسع البحث عن الموارد إلى سيارات إسعاف أبعد. يمكن للنظام اجتياز معدل معاملات اصطناعي والفشل في عبء العمل الذي يخلقه للأشخاص.
قدم مسار النشر أدلة تحذيرية. بعد تفويت الموعد النهائي في يناير، تم إدخال استقبال المكالمات المحوسب ودليل المواقع مع تفاصيل الحوادث المطبوعة للتخصيص اليدوي والإرسال الصوتي. جلب هذا الاستخدام الجزئي فوائد، لكن الشاشات تجمدت، وفشلت الخوادم أحيانًا، وتم الاحتفاظ بحادث في مخزن الطابعة المؤقت عندما كانت الطابعة مغلقة. كشفت التجارب اللاحقة على مستوى الأقسام عن تقارير حالة غير مكتملة، وتحديدات موقع غير موثوقة، وزيادة حمل الاتصالات، ومشاكل في المحطات المتنقلة، وأخطاء في الاقتراحات. لم تكن هذه أسبابًا للتخلي عن التكنولوجيا. كانت نتائج اختبار كان ينبغي أن تتحكم في التقدم.
شكلت حالة الراديو والمركبات حلقة تحكم حرجة للسلامة
اعتمدت صورة الموارد للنظام على حلقة تمتد من الطواقم والمركبات عبر المحطات المتنقلة والبنية التحتية اللاسلكية وبرمجيات الواجهة إلى CAD، ثم العودة عبر رسائل التعبئة. وجد التحقيق أن تأثير CAD على البنية التحتية للاتصالات لم يتم اعتباره بشكل صحيح ومنهجي. لم يُظهر أي حساب رسمي كيف سيقوم النظام الجديد بتحميل الاتصالات الحالية. اقتراح مراجعة سعة الشبكة اللاسلكية بعد التنفيذ الكامل قلب التسلسل المطلوب؛ كان يجب إظهار السعة قبل أن تعتمد عليها الخدمة.
جعلت البيئة التشغيلية التواصل المثالي غير قابل للتصديق. تضمنت لندن بقعًا سوداء لاسلكية ومركبات متحركة وفترات ذروة. في تغييرات الورديات، قد يؤدي تسجيل دخول الطواقم إلى ازدحام القنوات. تركت إرسالات الحالة الفاشلة أو المتأخرة CAD بصورة قديمة. يمكن لمحطة طرفية وشاشة مركزية أن تختلف بسبب مشاكل في روتينات الإقرار. يمكن لحركة الصوت المستخدمة لحل عدم اليقين أن تضيف هي نفسها ازدحامًا، بينما يمكن لتقييد الصوت أن يزيل التدقيق البشري الذي كشف عن التخصيصات الخاطئة أو المكررة.
كان لتحديد موقع المركبات الآلي حدود مماثلة. يمكن أن يكون الإرسال الحضري واستنتاج الموقع خاطئين في بعض الأحيان حتى لو كان المكون صالحًا للخدمة بشكل عام. لم تكن نظرة التحقيق المستقبلية أن تقنية الموقع يجب التخلص منها. بل كانت أن CAD يجب أن يتعرف ويتعامل بأمان مع معلومات الموقع غير الكاملة التي ستوفرها هذه التكنولوجيا حتمًا. لذلك تطلبت الموثوقية عند حدود المكون استجابة نظام واعية بعدم اليقين، وليس وعدًا بأن المكون لن يكون غير مؤكد أبدًا.
في 26 أكتوبر، أدى تعليم تقليل الاتصال الصوتي إلى تحسين معدل الإبلاغ عن عمليات التعبئة الناجحة بالبيانات. ومع ذلك، كان من غير المرجح تصحيح التخصيصات الخاطئة أو المتعددة بدون اتصال صوتي. يوضح هذا كيف يمكن لمقياس محلي أن يتحرك في الاتجاه الصحيح بينما تزداد سلامة النظام سوءًا. لم تثبت الرسائل الناجحة أن جهاز التحكم لديه صورة صحيحة أو أن الطاقم المقصود كان يذهب بالفعل إلى الحادث المقصود.
ينطبق نفس الدرس على الإبلاغ عن حالة الطاقم. لم يكن الضغط على سلسلة من الأزرار واجب مستخدم معزولًا؛ بل كان جزءًا من التحكم بالتغذية الراجعة. أثر عليه التدريب وتصميم الواجهة وضغط الحادث وحالة المعدات والتغطية الاتصالية والثقة. عندما صاغت الإدارة الحالة غير المكتملة بشكل أساسي على أنها سلوك قوة عاملة، قللت من وزن ظروف النظام التي جعلت الإبلاغ الصحيح صعبًا وواجب التصميم للتدهور الآمن عندما فشل الإبلاغ. يمكن أن يؤدي الامتثال في الخطوط الأمامية إلى تحسين المدخلات، لكنه لا يمكنه علاج تصميم أصبح غير مستقر كلما كانت المدخلات أقل من المثالية.
كان التدريب وملكية المستخدم جزءًا من النظام
وجد التحقيق أن الموظفين إيجابيون بشكل عام تجاه استخدام تكنولوجيا المعلومات لتحسين خدمات الإسعاف. كان عدم ثقتهم موجهًا إلى النظام الحالي وطريقة تقديمه. هذا مهم لأنه يرفض الصورة النمطية لقوة عاملة تقاوم الأتمتة من حيث المبدأ. لقد اختبر الأشخاص شاشات مقفلة، ومعلومات مركبات غير متناسقة، وعمليات إرسال غير ناجحة، وإجراءات متغيرة. كان انعدام الثقة جزئيًا ملاحظة حول الأدلة التشغيلية.
كان التدريب غير مكتمل وغير متسق. تم بعضه قبل وقت طويل من التنفيذ المؤجل، مما سمح للمهارات بالتدهور قبل الاستخدام. جعلت التغييرات البرمجية المستمرة مواد التدريب والروتينات المكتسبة غير مستقرة. تدرب موظفو غرفة التحكم على مستويات كفاءة مختلفة، لكن التغطية تفاوتت. تم تدريب الطواقم وموظفي غرفة التحكم بشكل منفصل إلى حد كبير على الرغم من أن الإرسال الناجح يتطلب من كل جانب فهم كيفية تأثير أفعاله على الآخر. اقترح التحقيق عناصر مشتركة حتى يتمكن كلاهما من فهم حلقة التحكم المشتركة والضغوط على كل دور.
غيّر التنفيذ الكامل أيضًا البيئة التشغيلية المادية والاجتماعية. تم إعادة تشكيل غرفة التحكم. تم فصل موزعي الموارد عن مشغلي الراديو ومصححي الاستثناءات. عمل الموظفون في مواقع غير مألوفة، دون النسخ الورقية المستخدمة أثناء التشغيل الجزئي، وبوصول أقل إلى الزملاء الذين كانوا يحلون معهم المشكلات سابقًا. تم وضع تطبيق دون تغيير تقني داخل نظام عمل تم تغييره حديثًا. لا يمكن لاختبار ترتيب الغرفة القديم أن يثبت الجديد.
تُختزل ملكية المستخدم أحيانًا إلى الموقف أو اتصالات التغيير. في هذه الحالة، كان لها معنى سلامة أكثر حدة. احتاج المستخدمون إلى دور شرعي في المتطلبات، وتصميم المحطة الطرفية، والإجراءات التشغيلية، والتجارب، والقبول. احتاجوا إلى رؤية العيوب تُحل والثقة في أن الإبلاغ عن مشكلة يمكن أن يغير موعدًا نهائيًا. بدون تلك السلطة، يصبح "تبني" العزم ضغطًا لتأييد قرار تم اتخاذه بالفعل.
توقعت الإدارة أيضًا من CAD فرض تغييرات في ممارسات العمل، بما في ذلك اختيار الموارد والحركة عبر مناطق المحطات. وصف التحقيق النظام بأنه قميص ضيق تشغيلي حاول الموظفون من خلاله الحفاظ على مرونة محلية. يمكن للبرمجيات دعم التغيير المتفق عليه، لكنها لا تستطيع تصنيع الاتفاق أو محو المعرفة الظرفية بالمواصفات. إذا أخذ طاقم مركبة أخرى أو حدد موظفون محليون موردًا أفضل، يجب على النظام إما استيعاب الممارسة الصحيحة أو يجب على المؤسسة تغيير الممارسة من خلال التشاور والتدريب والسياسة التشغيلية الخاضعة للمساءلة قبل أن تعتمد الأتمتة عليها.
أنتج 26 و27 أكتوبر فشلًا بدون تعطل تقني ضيق
في الساعة 07:00 من يوم 26 أكتوبر 1992، انتقلت LAS لأول مرة إلى الاستخدام الكامل للنظام المقصود في جميع أنحاء لندن. لم يتغير الكود فجأة في الأسابيع السابقة. كانت التغييرات الحاسمة تشغيلية: لا سجلات ورقية أو صناديق تنشيط كنسخ احتياطي، وغرفة تحكم معاد تشكيلها، وأدوار منفصلة، واقتراحات آلية كأساس للتخصيص، ومستقبلو مكالمات قادرون على تخصيص بعض الموارد. تمت إزالة عناصر التحكم التي ساعدت الموظفين على التعويض عن المعلومات غير الموثوقة أثناء التشغيل شبه اليدوي معًا.
كان التحقيق واضحًا في أن نظام CAD ولا مستخدميه كانوا جاهزين. كانت البرمجيات غير مكتملة، وغير معدلة بشكل كافٍ، وغير مختبرة بالكامل. مرونة الأجهزة تحت الحمل الكامل والتحول إلى خادم ثانٍ لم يتم اختبارها. بقيت مشاكل إرسال البيانات المتنقلة؛ كانت الثقة في تحديد الموقع الآلي مشروطة؛ لم يكن جميع الموظفين مدربين بالكامل؛ ولم يتم اختبار التصميم ضد معلومات غير دقيقة أو غير كافية. كان استخدام تخصيصات الموارد المولدة بالكمبيوتر فقط في هذه الحالة، وفقًا لحكم التحقيق، قرارًا عالي المخاطر.
مع زيادة النشاط من حمل مبكر خفيف، احتفظ النظام بحالة وموقع صحيحين لعدد أقل من المركبات. جعلت الغرفة وسير العمل الجديدان التصحيح البشري أصعب. مع عدد أقل من الموارد المتاحة ظاهريًا، أصبحت الاقتراحات أقل ملاءمة ووصلت عمليات البحث إلى أبعد. أنتجت التخصيصات الخاطئة أو المكررة أو المتأخرة المزيد من الاستثناءات. عادت المكالمات المغطاة إلى الانتباه عندما كان تسلسل الحالة المتوقع غير مكتمل. تراكمت قوائم الانتظار، وتباطأت المعالجة، وانتقلت الرسائل خارج الشاشة المرئية. واجه المشغلون المزيد من العمل مع قدرة أقل على إصلاح الحالة الأساسية.
ثم كثفت حلقة الواجهة العامة الحلقة الداخلية. دفعت الحوادث المتأخرة أو غير المغطاة المتصلين إلى الاتصال مرة أخرى. زادت التقارير المكررة والمعاودة من حجم الهاتف. يؤدي قلة عدد مستقبلي المكالمات وبطء النظام إلى تمديد أوقات الرد، مما قد يولد المزيد من المكالمات والمزيد من التأخير. رفض التحقيق الادعاء بأن 26 و27 أكتوبر كانا مشغولين بشكل استثنائي من حيث الحوادث أو المرضى الذين تم نقلهم. جاء الكثير من الزيادة الظاهرية من مكالمات مكررة غير محددة ومعاودة ناتجة عن التأخير.
يدعم هذا التسلسل الزمني بيانين يجب أن يبقيا معًا. أولاً، لم يتعطل نظام الكمبيوتر في 26 و27 أكتوبر بالمعنى التقني الضيق. لقد نفذ بشكل عام ما صُمم للقيام به. ثانيًا، تراكمت عيوب التصميم والتشغيل حتى أظهرت الخدمة أعراض فشل النظام، بما في ذلك تأخيرات استجابة غير مقبولة. قول أن الكمبيوتر "ظل يعمل" فقط سيخلط بين توفر العملية والتحكم الناجح في حالات الطوارئ. قول إنه تعطل تقنيًا سيمحو آلية الفشل الأكثر إفادة.
من أجل سلامة المرضى، تكون النتيجة واضحة بدون ادعاء إصابات غير مدعوم. تأخرت مكالمات الطوارئ، وأصبحت أوقات وصول سيارات الإسعاف غير مقبولة في بعض الأحيان، ولم يتمكن موظفو التحكم من الحفاظ على صورة موثوقة للحوادث والموارد. خدمة حرجة للسلامة فقدت أدلة القيادة في الوقت المناسب. نشأ الخطر قبل أن يتم تحديد عدد الضحايا النهائي: تعرض المرضى والمتصلون لعدم اليقين بشأن ما إذا كانت المساعدة قد تم تخصيصها، وما إذا كانت في طريقها، ومتى قد تصل.
لذلك فإن قرار التحول هو بوابة المساءلة المركزية. عرف القادة عن البرمجيات غير المكتملة، والمشكلات الخطيرة المفتوحة، ومخاوف الاتصالات، والفجوات التدريبية، وانعدام الثقة، والخطط البديلة غير المختبرة. كما واجهوا ضغوطًا مشروعة لتحسين الأداء. يشرح الضغط لماذا كانت النتيجة المبكرة جذابة؛ إنه لا يثبت الجاهزية. احتاج مالك القرار إلى سلطة لتفضيل الأدلة على التاريخ المعلن وسجل يوضح شروط القبول التي تم استيفاؤها. لم يستطع التحقيق فهم لماذا تم المضي قدمًا في التنفيذ الكامل مع وجود العديد من العيوب المعروفة.
كان تعطل 4 نوفمبر فشلًا مختلفًا
بعد مشاكل 26 و27 أكتوبر، عادت السيطرة إلى ترتيب شبه يدوي يشبه إلى حد كبير الترتيب السابق. لا تزال المكالمات والبحث عن الموقع تستخدم الكمبيوتر، وتم طباعة تفاصيل الحوادث، وحدد البشر الموارد، ويمكن للتعبئة استخدام CAD أو طابعة المحطة أو البيانات المتنقلة. ساعدت القنوات الصوتية في حل سوء الفهم. كان الموظفون أكثر ارتياحًا لهذا المزيج، وعمل بنجاح معقول حتى الساعات الأولى من 4 نوفمبر.
بعد وقت قصير من الساعة 02:00 من يوم 4 نوفمبر، تباطأ النظام ثم تجمد. تتبع التحقيق هذا التعطل الفعلي إلى خطأ برمجي بسيط تم إدخاله قبل حوالي ثلاثة أسابيع. استهلك الكود المرتبط بالتعبئة كمية صغيرة من ذاكرة الخادم دون تحريرها؛ أدى الاستخدام المتكرر في النهاية إلى استنفاد الذاكرة المتاحة. انتقد التحقيق الإهمال وعدم كفاية ضمان الجودة حول تغييرات الكود مع ملاحظة أيضًا أنه من غير المرجح أن يتم العثور على العطل من خلال اختبار المبرمج أو المستخدم التقليدي وحده.
التمييز مهم لأنه يمنع اختزال القضية بأكملها في ذلك الخطأ. لم يشرح عيب الذاكرة حلقات التغذية الراجعة في 26 و27 أكتوبر. ولا يجب أن يصبح قصة أخلاقية عن مبرمج واحد. تمتلك الخدمة الحرجة مراجعة للتغييرات، وضمان جودة مستقل، ومراقبة، وإنذارات سعة، واسترداد، وذلك على وجه التحديد لأن عيبًا محليًا صغيرًا يمكن أن يفلت. تكمن المساءلة في سبب تمكن عيب واحد من التراكم إلى فقدان الخدمة دون اكتشاف ولماذا لم يحتويه الاسترداد.
لم يحافظ التبديل التلقائي إلى خادم احتياطي على وضع التشغيل. تم تحديد الخطط البديلة للنظام الورقي المقصود، بينما تمت إضافة الطابعات كإجراء مؤقت بعد تفويت الموعد النهائي الأصلي. لم يتم اختبار تأثير فشل الخادم على هذا التكوين القائم على الطابعة، ولم يجد التحقيق أي سجل على أن التبديل التلقائي نفسه قد تم إثباته بشكل كافٍ. عندما حدث العطل، قام الموظفون بتسجيل المكالمات باستخدام التسجيلات الصوتية وعادوا إلى التحكم اليدوي الكامل القائم على الورق. كان الاضطراب التشغيلي محدودًا بسبب الحمل المنخفض خلال الليل، وليس بسبب استرداد تقني تم إثباته بنجاح.
اتبعت المساءلة السيطرة العملية على البوابة
التحكم في تفاصيل التنفيذ وجودة الكود والإبلاغ عن التقدم والأدلة على أن التغييرات تصرفت كما ادُّعي كانت من مسؤولية المورد. كان عليه التكوين المنضبط والإفصاح الصادق عندما تجاوز الجدول الزمني قدرته. لكن المورد لم يتحكم في الخدمة بأكملها، ولم يختر كل متطلب، ولم يدرب كل مستخدم، ولم يمتلك ممتلكات الراديو، ولم يكن لديه سلطة منفردة لوضع CAD في التشغيل عبر لندن. مساءلة المورد حقيقية ومحدودة.
سيطرت الإدارة التنفيذية لـ LAS على الطموح والجدول الزمني وسياق التكامل وقرار المضي قدمًا. تحكمت في ما إذا كانت الضمانات الورقية والصوتية لا تزال متاحة، وما إذا كان التدريب كاملاً، وما إذا كانت العمليات قد قبلت الإجراءات الجديدة، وما إذا كان مدير مشروع مستقل ذو خبرة ووظيفة جودة قد تم إشراكهما. حقيقة أن المديرين كانوا يعملون بجد تحت الضغط لا تزيل هذه الضوابط. بل تجعل معايير الجاهزية الصريحة أكثر أهمية، لأن الالتزام الشخصي يمكن أن يُخطئ في اعتباره تأكيدًا موضوعيًا.
كان على قيادة المشروع والتشغيل ترجمة تقارير المكونات إلى ادعاء شامل. يعني ذلك التوفيق بين المشكلات المفتوحة وإصدارات البرمجيات وأداء الاتصالات ودقة الموقع والتوظيف وتكوين الغرفة ونتائج الخطط البديلة. كانت سلطة تحول محددة بحاجة إلى رؤية تلك الأدلة، وسماع الاعتراضات التقنية والمستخدم المستقلة، والحصول على حق لا لبس فيه في التأخير. إذا لم يكن لدى أي شخص كل من صورة النظام وسلطة الإيقاف، يمكن أن يتقدم المشروع لأن كل مشارك يفترض أن مشاركًا آخر يمتلك المخاطر المتبقية.
سيطر مجلس LAS على التدقيق في الحوكمة. وجد التحقيق أنه تلقى درجة مضللة من الارتياح بشأن خبرة المورد ذات الصلة ولم يتلق معلومات مرجعية سلبية. بشكل أوسع، قبل تأكيدات تنفيذية بينما لم يختبر أي مراجعة مستقلة الحالة الحقيقية للمشروع. لم تتطلب مساءلة المجلس من الأعضاء اختيار أدوات البرمجة. طلبت منهم أن يسألوا عما إذا كان نظام التحكم في حالات الطوارئ الرائد لديه ضمان مستقل، ونتائج حمل واقعية، وخطة بديلة مختبرة، ومخاطر صريحة غير محلولة.
أدارت هيئة الصحة الإقليمية في جنوب غرب التايمز LAS على مسافة ذراع. تم اتباع قواعد المشتريات الرسمية، ولم تطلب LAS مساعدة تقنية إقليمية. ومع ذلك، واجهت الهيئة مخاوف مرارًا وقبلت تأكيدات أنه سيتم حلها. خلص التحقيق إلى أن خطوط المساءلة بدت آمنة على الورق لكنها لم تنتج معلومات كافية للمجلس أو المنطقة لممارسة مسؤولياتهم. لا يمكن أن يعني الإشراف على مسافة ذراع البعد عن الأدلة عندما تكون الخدمة المفوضة حرجة للسلامة.
عملت المسؤولية الوزارية على مستوى آخر. لم يكن البرلمان المحقق التقني الأساسي، ولا ينبغي معاملة التصريحات التي تم الإدلاء بها أثناء النقاش الحزبي على أنها نتائج حول أسباب البرمجيات. يظهر Hansard سلسلة المساءلة العامة. في 28 أكتوبر، أعلن وزير الدولة عن دعم صوتي مباشر، وتحقيق خارجي، وتقارير منتظمة من قيادة LAS المؤقتة عبر الهيئة وإدارة NHS لإبقاء الوزراء على اطلاع. بعد أن أبلغ التحقيق في فبراير 1993، شككت فيما إذا كانت المساءلة للوزراء قوية بما فيه الكفاية، وطلبت مقترحات لتعزيزها، ولاحظت خططًا لمدير تكنولوجيا المعلومات وتنفيذ CAD على مراحل.
التحكم في أفعال محددة مثل الإبلاغ عن الحالة والاستجابة للتعبئة كان من مسؤولية الموظفين في الخطوط الأمامية، لكنهم لم يشاركوا بالتساوي في التحكم في المشتريات ونطاق الاختبار وتصميم الغرفة أو التحول. كانت تجربتهم أيضًا دليلاً يحتاج القادة إلى استخدامه. معالجة الطواقم على أنهم مقاومون فقط حولت التحذيرات حول المحطات الطرفية والرسائل اللاسلكية والملاءمة التشغيلية إلى سردية سلوكية. تتطلب المساءلة التمييز بين واجب المستخدم في اتباع إجراء عملي وواجب الإدارة في إثبات أن الإجراء والتكنولوجيا يظلان آمنين عندما تحدث أخطاء بشرية واتصالات عادية.
لا يتطلب خطر سلامة المرضى حصيلة وفيات مخترعة
غالبًا ما تُعاد رواية قصة لندن بعدد محدد من الوفيات المنسوبة إلى سيارات الإسعاف المتأخرة. يوفر التحقيق حدودًا أكثر صرامة. ذكر أن محاكم الطب الشرعي فقط هي التي يمكنها تحديد ما إذا كان التأخير تسبب في وفاة، وأنه لم تستنتج أي محكمة طب شرعي أن وصول سيارة إسعاف متأخر تسبب في وفاة مريض في الحالات التي تم النظر فيها آنذاك. كرر الرد البرلماني في فبراير 1993 هذا الموقف.
لا يجب توسيع هذا الاستنتاج إلى "لم يمت أحد"، "لم يصب أحد بأذى"، أو "الفشل كان غير ضار". إنه بيان حول ما استنتجه أطباء الطب الشرعي حول السببية، وليس تعدادًا لكل نتيجة. أكد التحقيق أيضًا على الضيق الناجم عن التأخير في الرد والإرسال والوصول. سجل أداء استجابة غير مقبول وخدمة طوارئ متدهورة. هذه أسباب كافية لتحليل سلامة المرضى.
تبدأ مساءلة السلامة بالتعرض لمخاطر غير مسيطر عليها، وليس فقط بنقطة نهاية قاتلة مثبتة. عندما لا يعرف جهاز التحكم ما إذا كانت حادثة مغطاة، أو عندما تكون التعبئة مكررة أو متأخرة، أو عندما تتراكم المكالمات لأن المتصلين السابقين ليس لديهم إجابة موثوقة، يكون القادة قد فقدوا الأدلة اللازمة لحماية المرضى. عدم اليقين نفسه له عواقب تشغيلية. لا يلزم وجود نتيجة قانونية أو سريرية لاحقة حول السببية قبل أن تتحرى المؤسسة وتصلحه.
تعمل لغة الإصابات الدقيقة أيضًا على تحسين التحليل السببي. يمكن لحصيلة دراماتيكية أن تسحب الانتباه نحو الادعاء الأكثر إثارة للعاطفة وتبتعد عن الضوابط الموثقة بشكل واضح. يدعم التحقيق حسابًا قويًا للمكالمات المتقطعة والتأخيرات غير المقبولة والتخصيصات غير الموثوقة والضيق العام والثقة المتضررة. هذه النتائج تجعل فشل الجاهزية خطيرًا دون تحويل الادعاء إلى حقيقة.
كانت السلطة البديلة وسلطة التحول ضوابط حوكمة
تظهر تجربة LAS لماذا يجب تصميم خطط الاستمرارية جنبًا إلى جنب مع النظام الأساسي. لم تكن النسخ الورقية والاتصال الصوتي ومعرفة المحطة والتخصيص اليدوي مجرد طرق قديمة تنتظر خارج التكنولوجيا. أثناء التشغيل الجزئي، سمحت للأشخاص باكتشاف الحالة السيئة وممارسة الحكم وإبقاء الحوادث مرئية. إزالتها غيرت تحمل الفشل للخدمة بأكملها. كان هذا التغيير بحاجة إلى حالة قبول خاصة به.
يجب أن يحدد الوضع المتدهور ما الذي يسببه، ومن يعلنه، وما هي الوظائف التي تستمر، وكيف يتم التوفيق بين الحوادث الجارية، وكيف يعرف الموظفون أي سجل موثوق. يجب تجربته تحت حمل واقعي. تبديل الخوادم هو مجرد طبقة واحدة. إذا تصرفت الطابعات أو المحطات الطرفية أو قوائم الانتظار أو تخصيص العمل بشكل مختلف بعد التحول، فقد لا يحافظ التوفر التقني على القيادة. إذا لم يتمكن الموظفون من استرداد قائمة حوادث كاملة، فقد فشلت الخطة البديلة حتى أثناء اتصال الأجهزة.
سلطة التحول هي النقطة التي تصبح فيها تلك الضوابط ملزمة. يجب اتخاذ القرار مقابل أدلة محددة مسبقًا: لا توجد مشكلة غير محلولة قادرة على تدهور الخدمة بشدة؛ تكوين مستقر؛ اختبار متكامل للحمل الكامل؛ حقن الفشل عبر الراديو والموقع والمحطات الطرفية؛ تدريب على الدور الحالي وكفاءة ملحوظة؛ قبول المستخدم والتشغيل؛ سعة استثناءات مأهولة؛ وانتقال موضح من وإلى الأوضاع اليدوية أو شبه اليدوية. يجب أن يحمل أي شرط غير مستوفٍ مالك مخاطر مسمى وسببًا مسجلاً لكون التعرض مقبولاً.
يجب أن تكون السلطة أيضًا قادرة على التوقف دون عقوبة تنظيمية. وصف التحقيق ثقافة اعتبرت فيها المواعيد النهائية جامدة ويصعب تحديها. طريق المنع الموجود فقط على هيكل تنظيمي ليس تحكمًا تشغيليًا. يحتاج القادة إلى حماية المعارضة التقنية وفي الخطوط الأمامية، وطلب تعليقات مكتوبة على الاعتراضات، ومنع التواريخ العامة أو التكاليف الغارقة من تغيير عتبات القبول بصمت.
أظهرت أدلة الإصلاح أن الأتمتة يمكن أن تكتسب السلطة
كانت أول توصية للتحقيق بخصوص CAD هي أن تواصل LAS تخطيط نظام إرسال بمساعدة الحاسوب. وجد دعمًا إجماعيًا للتكنولوجيا التي يمكن أن تحسن خدمة الإسعاف ووصف العملية الورقية بأنها غير فعالة. تطلبت خطته المستقبلية نظامًا يتناسب مع الهيكل التنظيمي والإجراءات المتفق عليها، وموثوقًا ومرنًا مع نسخ احتياطية مختبرة، ويملكه الإدارة والموظفون، ويُقدم وفق جدول زمني يسمح بالتشاور وضمان الجودة والاختبار والتدريب، ويُنشر خطوة بخطوة.
ربط التسلسل المقترح زيادة السلطة بزيادة الإثبات. يمكن لمرحلة أولى مؤقتة استعادة استقبال المكالمات المحوسب ووظائف دليل المواقع فقط بعد مراجعة جودة البرمجيات والاختبار والطباعة الأقوى وإعادة التدريب. ستبقى تفاصيل الحوادث متاحة للموزعين البشريين. من شأن مرحلة ثانية أن توفر موقعًا وحالة موثوقين للمركبات بينما لا يزال الموزعون البشريون يختارون الموارد. تطلبت مراجعة اتصالات متخصصة وثقة أفضل في البنية التحتية.
فقط بعد القبول وخبرة تلك المرحلة ستنتقل التعبئة من الصوت إلى البيانات المتنقلة. يمكن أن تكون مقترحات الموارد الحاسوبية أولاً اقتراحات للموزعين البشريين. سيحصل مستقبلو المكالمات على سلطة التخصيص فقط عندما تكتسب المقترحات والاتصالات والحالة الأساسية الثقة. في كل مرحلة، كانت المرونة والتخطيط للطوارئ والخطط البديلة تتطابق مع الحاجة إلى خدمة مستمرة. لم يكن هذا تسليمًا بطيئًا لذاته. كل مرحلة عزلت ادعاءً يمكن ملاحظته تحت ظروف حية قبل إضافة الاعتماد التالي.
صاحب التدريج التقني إصلاح الحوكمة. أوصى التحقيق بمدير مشروع ذي خبرة، ولجنة فرعية للمشروع من المجلس بتمثيل عبر الخدمة، وربما مشورة من أشخاص خارجيين ذوي خبرة، ومدير تكنولوجيا معلومات بوصول مباشر إلى المجلس. دعا أيضًا إلى توجيه أفضل للمشتريات النوعية، ومراجعة اتصالات، وإبلاغ مفتوح بأداء الاستجابة للهيئات العامة وأعضاء البرلمان في لندن. وضعت هذه التدابير الأدلة حيث يمكن للسلطة رؤيتها والتصرف بناءً عليها.
يسجل Hansard الجانب العام من ذلك الإصلاح. في فبراير 1993، قالت الحكومة إن مدير تكنولوجيا المعلومات سيشرف على التنفيذ المرحلي وسعى لخطوط أقوى من LAS عبر الهيئة إلى الوزراء. في أكتوبر، أبلغ إجابة مكتوبة عن توجيهات جديدة لـ NHS بشأن شراء نظم المعلومات الفعالة وتقارير إقليمية منتظمة عن تنفيذ توصيات التحقيق، بما في ذلك CAD المستقبلية. البيانات البرلمانية لا تثبت أن كل إصلاح نجح، لكنها تظهر أن الجاهزية التقنية أصبحت مسألة صريحة للرقابة المؤسسية.
وصفت دراسة حالة لاحقة خاضعة لمراجعة الأقران تنفيذًا أكثر نجاحًا لـ CAD في LAS بأنه تحول. حددت مقارنتها اهتمام الإدارة باحتياجات المستخدمين، ومشاركة المستخدمين، وموارد أكبر، وجدول زمني أكثر مرونة مدفوع بالقبول، ومشاريع بنية تحتية بنت الثقة، والمشاركة والنماذج الأولية، والاختبار الشامل، والتنفيذ البسيط على مراحل، وبناء الثقة. هذه النتائج هي تحليل ثانوي للبرنامج اللاحق، وليست بديلاً عن رواية التحقيق لعام 1992.
كما أنها لا تثبت أن تدخلاً واحدًا تسبب في النجاح اللاحق. تحولات المنظمات لها تأثيرات عديدة، واختلفت الظروف اللاحقة. قيمتها مقارنة: التنفيذ اللاحق عالج جميع الفئات التي كانت إشكالية تقريبًا. يظهر التباين كيف يبدو الإصلاح عندما يُعبر عنه في ظروف تشغيلية بدلاً من شعارات. يشارك المستخدمون؛ تكتسب البنية التحتية الثقة؛ الاختبارات شاملة؛ التنفيذ الأول أبسط؛ التوقيت يتبع القبول؛ تنمو الثقة من خلال الأدلة المقدمة.
تعتمد الشرعية المؤسسية على حالة الإرسال القابلة للملاحظة
تطلب خدمات الطوارئ من الجمهور الثقة بقرارات لا يمكن للمتصلين فحصها. لا يرى المتصل قائمة انتظار التخصيص أو التبادل اللاسلكي أو قاعدة بيانات الحالة. لذلك تعتمد الشرعية المؤسسية على أن تثبت الخدمة داخليًا، وتشرح علنًا، أن تلك الآليات الخفية تحافظ على قيادة موثوقة. عندما لا تستطيع الخدمة معرفة ما إذا كانت سيارة إسعاف متاحة حقًا أو ما إذا كانت التعبئة قد وصلت، تنهار الثقة لسبب ما.
المساءلة ليست لومًا جماعيًا بعد انقطاع الخدمة. إنها التخصيص المسبق للواجبات لإنتاج الأدلة والطعن فيها والعمل بناءً عليها. يُثبت المنفذ المكون. يُثبت المُدمج الخدمة. تُثبت العمليات أنه يمكن أداء العمل. تحمي القيادة الوقت والموارد وسلطة الإيقاف. يستجوب المجلس الجاهزية بشكل مستقل. تطلب هيئات الإشراف أداءً شفافًا وإصلاحًا.
جعلت خدمة إسعاف لندن من CAD اختبارًا لمساءلة سلامة المرضى لأن أتمتة الإرسال سُمح لها بأن تصبح موثوقة بينما ظلت صورتها عن الخدمة هشة. لم يكن الرد الدائم هو رفض الكمبيوتر. بل كان جعل السلطة مشروطة: لا شيء من الأتمتة يتحكم في المكالمات الحقيقية والطواقم وسيارات الإسعاف حتى تستطيع المؤسسة إظهار كيف تظل صادقة تحت الحمل، وكيف يتعافى الناس عندما لا تكون كذلك، ومن لديه القوة للإيقاف عندما تقصر الأدلة.
المصادر
- https://www.dcs.gla.ac.uk/~johnson/teaching/safety/reports/las.pdf
- http://www0.cs.ucl.ac.uk/staff/a.finkelstein/papers/lascase.pdf
- http://www0.cs.ucl.ac.uk/staff/a.finkelstein/las.html
- https://www0.cs.ucl.ac.uk/staff/a.finkelstein/papers/lascase.pdf
- https://hansard.parliament.uk/commons/1992-10-28/debates/c624d1cc-04d3-416b-a1de-89e68403edd2/LondonAmbulanceService
- https://api.parliament.uk/historic-hansard/commons/1992/oct/28/london-ambulance-service
- https://api.parliament.uk/historic-hansard/written_answers/1992/nov/09/london-ambulance-service
- https://api.parliament.uk/historic-hansard/commons/1993/feb/25/london-ambulance-service-inquiry
- https://api.parliament.uk/historic-hansard/written_answers/1993/oct/21/london-ambulance-service
- https://api.parliament.uk/historic-hansard/commons/1991/dec/20/fire-and-emergency-services-london
- https://link.springer.com/article/10.1057/palgrave.ejis.3000541
- https://link.springer.com/content/pdf/10.1057/palgrave.ejis.3000541.pdf
- https://www.floppybunny.org/robin/web/virtualclassroom/chap12/s4/articles/london_ambulance_1999_davies.pdf
- https://arxiv.org/abs/1003.3880
- https://arxiv.org/pdf/1003.3880
- https://www.utdallas.edu/~chung/SP/Ambulance-Dispatch-System.pdf
- https://erichmusick.com/pdf/writings/technology/1992-london-ambulance-cad-failure.pdf
- https://cs.stanford.edu/people/eroberts/courses/cs181/projects/1999-00/critical-systems/commercial.htm
- https://www.staff.city.ac.uk/~veselin/EE3421/LASFailure.pdf

