الموضوع 4.1 — المنصات والخدمات المشتركة

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

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

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

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

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

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

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

عدة أفكار مرتبطة تجلس تحت هذا. الخدمات المشتركة هو النمط التنظيمي الأقدم لتقديم قدرة مرة واحدة لأجزاء عديدة من مؤسسة بدلًا من تكرارها في كل منها. تُوسِّع البنية التحتية العامة الرقمية هذا لمستوى مجتمع بأكمله — كتل البناء المشتركة، القابلة لإعادة الاستخدام، القابلة للتشغيل البيني (الهوية، الدفعات، تبادل البيانات) التي تُبنى عليها خدمات عامة وخاصة. "الحكومة كمنصة"، عبارة صاغها Tim O'Reilly وتبنّتها فرق حكومة رقمية عالميًا، تُطبِّق نفس المنطق على الدولة: تُقدِّم الحكومة مكونات مشتركة، وتُشكِّل الأقسام خدمات منها بدلًا من أن يبني كل منها المكدس الكامل.

تقنيًا، غالبًا تكشف المنصات قدراتها من خلال واجهة برمجة تطبيقات (API) — عقد مُعرَّف يتيح لنظام استخدام قدرة نظام آخر دون معرفة داخلياته. غالبًا تستمد من نماذج سحابية منصة كخدمة (PaaS)، وتعتمد المنصات الوطنية المشتركة عادة على الاستئجار المتعدد، حيث تخدم نسخة واحدة مؤسسات كثيرة بينما تحفظ بياناتها وتهيئتها منفصلة.

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

في الصحة تحديدًا، الخدمات الوطنية المشتركة جزء من المشهد بالفعل. أسَّست برامج تاريخية مثل NHS Connecting for Health NHS Spine، مجموعة خدمات وطنية تحمل بيانات جوهرية مثل Personal Demographics Service. تشمل المكافئات الحديثة APIs وطنية، NHS login لمصادقة المواطن، وNHS Notify للرسائل — قدرات مُقدَّمة بحيث لا تحتاج خدمات فردية إعادة بنائها. حيث تُقدِّم منصة طريقة مشتركة لإثبات من هو شخص، غالبًا تكشف تسجيل دخول واحد بحيث يُصادِق طبيب مرة واحدة بدلًا من مرارًا. يتعلق هذا الموضوع بكيفية بناء وتشغيل مثل هذه المنصات؛ تفاصيل من أنت وماذا يمكنك فعله تنتمي للموضوع 4.2 — إدارة الهوية والوصول، والمعايير التي تتيح للأنظمة تبادل البيانات تنتمي للموضوع 4.3 — قابلية التشغيل البيني ومعايير البيانات.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بدلًا من تكليف منصة ICS كبرى، يبدؤون نحيفين. يُقيمون خدمة مشتركة واحدة تفعل شيئًا واحدًا جيدًا: تُغلِّف NHS login وService Personal Demographics الوطنية خلف API نظيف وموثَّق ببيئة اختبار، بحيث تستطيع أي فرقة التحقق من هوية مواطن واسترجاع سجل ديموغرافي مؤكَّد من خلال مسار مدعوم واحد. فريق منصة صغير من خمسة يُعامله كمنتج. يُنشِرون دليل طريق-مُعبَّد، يُقدِّمون إدخالًا ذاتي الخدمة، ويحدِّدون هدفًا بأن فرقة جديدة ينبغي أن تُنجِز مكالمتها الناجحة الأولى في غضون يوم. بشكل حاسم، لا يُفوِّضونها. يجعلونها الخيار الأسهل ويتركون فريق الجناح الافتراضي أول متبنٍ راغب.

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

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

شركة ناشئة#

نادرًا ما تبني شركة تقنية صحية ناشئة منصات للآخرين؛ تبني عليها. تأتي رافعتك من استهلاك منصات وطنية وسحابية — NHS login، APIs وطنية، خدمات مُدارة لمزود سحابي — بحيث تصرف فرقتك الصغيرة طاقتها على المشكلة السريرية، لا إعادة اختراع الهوية أو الرسائل. احترس من الارتباط مع ذلك: اختر معايير مفتوحة واحفظ بياناتك قابلة للنقل، لأن القدرة التي تستأجرها برخص اليوم يمكن أن تُصبح الاعتمادية التي تُقيِّدك غدًا. داخليًا، احفظ "منصتك" الخاصة نحيفة لدرجة اللامرئية تقريبًا؛ فريق من شخصين لا يحتاج تجريدًا لمسار ذهبي، يحتاج الشحن. الانضباط هو معرفة متى نموت بما يكفي بحيث تستحق قدرة داخلية مشتركة الاستخراج.

شركة صغيرة#

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

مؤسسة كبيرة#

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

حكومة#

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

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

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

نموذج النضج#

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

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

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

• GOV.UK Service Manual and the Government Digital Service writing on government as a platform and common components.
• Matthew Skelton and Manuel Pais, Team Topologies — platform teams, thinnest viable platform, and cognitive load.
• NHS England developer and API guidance (NHS login, NHS Notify, national APIs, and the Spine services).
• DCB0129 and DCB0160 clinical risk management standards for health IT systems.
• The World Bank and United Nations writing on digital public infrastructure and reusable public building blocks.
• Tim O'Reilly, "Government as a Platform", in Open Government (O'Reilly Media).

المراجع#

1. Digital public infrastructure — ويكيبيديا — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — ويكيبيديا — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — ويكيبيديا — https://en.wikipedia.org/wiki/API
4. Platform as a service — ويكيبيديا — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — ويكيبيديا — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — ويكيبيديا — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — ويكيبيديا — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — ويكيبيديا — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — ويكيبيديا — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — ويكيبيديا — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation