Digital Endpoints والـWearables في التاريخ الطبيعي للأمراض النادرة

1. ابدأ بالشيء المهم للمريض لا بالجهاز المتاح

امتلاك ساعة أو خاتم ذكي لا يخلق endpoint مفيدة تلقائيًا. البداية الصحيحة هي تحديد aspect of health الذي يهم المرضى ومقدمي الرعاية والباحثين: القدرة على المشي خارج المنزل، الاستيقاظ الليلي، نوبات السقوط، النشاط اليومي، tremor، التنفس أو وظيفة أخرى. بعد ذلك نحدد concept of interest ثم measure ثم التقنية القادرة على قياسه. هذا التسلسل يمنع اختيار metric لأنها سهلة التصدير من vendor dashboard. في الأمراض النادرة قد تكون outcome صغيرة التغير أو خاصة بمرحلة معينة، لذلك يجب أن يسبق اختيار الجهاز فهم التاريخ الطبيعي والمدى الوظيفي المتوقع وعبء القياس على المريض.

اكتب measurement chain في سطر واحد

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

2. فرّق بين sensor signal وdigital measure وendpoint

raw acceleration أو photoplethysmography أو gyroscope stream ليست endpoint. الإشارة الخام تمر بتنظيف ومعايرة وخوارزمية تنتج measure مثل cadence أو sleep duration أو tremor amplitude. بعدها قد تدخل measure في endpoint محددة بالتوقيت وطريقة التلخيص والمقارنة. خلط هذه الطبقات يجعل كلمة validated غامضة: قد يكون sensor دقيقًا في المختبر لكن algorithm غير صالح لسكان الدراسة، أو تكون measure جيدة تقنيًا لكنها لا تعكس تغيرًا ذا معنى سريريًا. احفظ تعريف كل طبقة ورقم نسختها وinput/output المتوقع حتى يمكن تتبع الخطأ وإعادة التحليل.

3. context of use يحدد مقدار الدليل المطلوب

نفس wearable قد يكون مناسبًا لاكتشاف اتجاه استكشافي وغير مناسب كprimary endpoint في تجربة حاسمة. اكتب population والمرض والمرحلة ومكان الاستخدام ومدة القياس ودور measure في القرار. هل الهدف natural history فقط، enrichment، monitoring، safety signal، exploratory outcome أو endpoint رئيسية؟ كلما زاد أثر القرار المطلوب من القياس زادت الحاجة إلى evidence أقوى وcontrols أوضح. fit-for-purpose ليست صفة دائمة للجهاز؛ هي علاقة بين الأداء وسياق الاستخدام المقصود.

4. verification تسأل هل hardware يعمل كما ينبغي

في V3 تبدأ verification على مستوى الجهاز ومكوناته: هل sensor يسجل ضمن المواصفات، ما sampling rate الحقيقي، ما حدود الدقة والضجيج، كيف يتأثر بالحرارة أو الحركة أو وضع الجهاز، وما ثبات البطارية والساعة الداخلية؟ قد يقدم المصنع بعض الأدلة، لكن فريق الدراسة يحتاج معرفة ما ينطبق على configuration المستخدمة. إذا غيّر vendor نموذج hardware أو sensor component خلال الدراسة فلا تفترض التكافؤ. خزّن device model وserial أو batch عند الحاجة وfirmware version ووقت التفعيل وربطها بكل فترة قياس.

اختبار bench لا يثبت الصلاحية السريرية

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

5. analytical validation تختبر الخوارزمية في الواقع المستهدف

الـalgorithm التي تحول raw signal إلى gait speed أو sleep stages أو tremor measure تحتاج مقارنة بمرجع مناسب وفي نطاق حركات يشبه المرضى الحقيقيين. قيم accuracy وprecision وbias وlimits of agreement حسب use case، ولا تعتمد correlation وحدها؛ قد تكون العلاقة مرتفعة مع انحياز ثابت كبير. اختبر subgroups المهمة مثل الأطفال، مستخدمي الكراسي، المشية البطيئة جدًا أو الحركات اللاإرادية. إذا كان المرجع نفسه ضعيفًا فستقيس الاتفاق مع أداة غير مستقرة. احتفظ بنسخة algorithm ومعاملاتها لأن أي update قد تغير كل القيم المشتقة من الإشارة نفسها.

6. clinical validation تسأل هل measure تعني ما ندعيه

بعد إثبات أن الخوارزمية تقيس metric بدقة، يجب ربط metric بالحالة أو الوظيفة أو الخبرة السريرية في population المقصودة. قد يكون step count مضبوطًا هندسيًا لكنه غير حساس للتدهور المهم في مرض معين، أو يتغير بسبب المدرسة والعمل والطقس لا المرض. اختبر known-groups validity، association مع COAs مناسبة، responsiveness، وتوقعات trajectory من natural history. لا تجعل هدف clinical validation مجرد الحصول على correlation دالة؛ يجب أن يكون معنى التغير وسبب ارتباطه بالconstruct واضحين.

7. لا تستورد cut-off من مجتمع مختلف

عتبة inactivity أو sleep efficiency أو gait speed المبنية على بالغين أصحاء قد لا تناسب طفلًا بمرض عصبي عضلي أو شخصًا يستخدم device مساعد. thresholds تحتاج population-specific evidence أو تبريرًا قويًا. إذا لم توجد عتبة مستقرة، استخدم measure مستمرة مع uncertainty بدل تحويلها مبكرًا إلى طبيعي وغير طبيعي. كذلك لا تفترض أن minimal important difference لمقياس عيادي ينطبق مباشرة على metric رقمية مختلفة.

8. meaningful change يجب أن يُبنى لا يُخمن

اسأل المرضى ومقدمي الرعاية ما التغير الذي يلاحظونه ويهمهم، ثم اربط ذلك بتوزيع digital measure وanchors مناسبة. استخدم أكثر من مصدر عندما يكون ممكنًا: patient global assessment، performance measure، milestone أو clinician judgment. لا يكفي distribution-based threshold وحده لأنه يخبرك بحجم التغير إحصائيًا لا معناه. في ultra-rare cohort قد تكون estimates غير مستقرة؛ يمكن أن تبدأ range للمعنى وتحدثها مع بيانات أكثر بدل إعلان رقم ثابت مبكرًا.

9. wear location جزء من تعريف القياس

وضع الجهاز على الرسغ أو الكاحل أو الخصر يغير الإشارة والخوارزمية. حتى الاتجاه والشد وطريقة التثبيت قد تؤثر في بعض measures. اكتب instructions مصورة وبسيطة، درّب المستخدمين، وسجل deviations المهمة. إذا سمحت بعدة مواقع يجب أن تثبت comparability أو تعالجها كconfigurations مختلفة. في أطفال أو اضطرابات حسية قد يكون تحمل location عاملًا حاسمًا؛ endpoint لا قيمة لها إذا كان half of participants يرفضون ارتداء الجهاز.

10. wear time ليست رقمًا سحريًا

قاعدة عشرة ساعات يوميًا أو أربعة أيام أسبوعيًا قد تأتي من مجال آخر ولا تناسب مرضك. حدّد minimum wear time بناء على variability داخل اليوم والأسبوع والهدف الإحصائي. افحص reliability عندما تستخدم يومًا مقابل ثلاثة أو سبعة أيام، واختبر weekday/weekend differences. لا تحذف اليوم تلقائيًا إذا كان أقل من threshold من دون فهم سبب النقص. يمكن أن يكون non-wear مرتبطًا بالتعب أو تهيج الجلد أو دخول المستشفى، أي أنه يحمل معلومات عن الحالة نفسها. خزّن wear-time detection algorithm ونسختها مثل أي algorithm أخرى.

11. non-wear لا يساوي inactivity

فترة بلا حركة قد تعني أن المريض ساكن فعلًا، أو أن الجهاز على الطاولة، أو يشحن، أو أُزيل بسبب ألم أو حساسية جلدية. يجب أن تفصل algorithm قدر الإمكان بين non-wear والسكون السريري، وأن تحفظ reason codes عندما يبلغ المشارك عن إزالة الجهاز. إذا خلطت الاثنين قد يبدو الشخص أقل نشاطًا فقط لأنه أقل التزامًا بالارتداء. اختبر non-wear detection في population المستهدفة، خصوصًا لدى من لديهم حركة قليلة جدًا، لأن الخوارزميات المصممة للبالغين الأصحاء قد تعتبر السكون الحقيقي إزالة للجهاز.

12. missing wearable data قد تكون معلومة عن المرض

الفقد الرقمي ليس عشوائيًا دائمًا. قد يتوقف المريض عن الارتداء عند تدهور شديد، دخول المستشفى، fatigue، skin irritation، أو صعوبة الشحن. لذلك خزّن سبب الفقد والوقت والتقنية المتأثرة بدل استبداله بمتوسط. افحص missingness حسب شدة المرض والعمر والموقع واليوم والأسبوع، وميّز device failure من participant choice ومن protocol deviation. إذا ارتبط الفقد بالحالة نفسها، فإن complete-case analysis قد يجعل cohort تبدو أكثر صحة مما هي عليه. يجب أن تتضمن خطة التحليل sensitivity analyses لافتراضات مختلفة حول البيانات غير المرصودة.

لا تعاقب المشارك بسبب مشكلة تقنية

إذا فشل sync أو نفدت البطارية لا تُسجل اليوم كعدم التزام سلوكي. افصل technical adherence عن participant adherence. هذا مهم في دراسات المرض النادر لأن بضعة أيام مفقودة لشخص واحد قد تؤثر في المتوسط أكثر من cohort كبيرة.

13. احتفظ بالـraw data عندما تسمح الحقوق والخصوصية

القيمة المشتقة قد تصبح غير قابلة لإعادة الحساب إذا تغيرت algorithm أو اكتُشف خطأ. لذلك خطط للاحتفاظ بالإشارة الخام أو أقرب representation ممكنة وفق consent والحقوق والقدرة التخزينية، مع checksum وmetadata. إذا كان vendor يمنع الوصول إلى raw signal، سجّل ذلك كقيد تصميمي قبل اختيار الجهاز. احفظ أيضًا derived outputs كل release بحيث يمكن تتبع النتيجة إلى المدخلات والخوارزمية. لا يعني الاحتفاظ بالraw نشرها؛ يمكن أن تبقى في بيئة محكومة مع access policy واضحة.

14. الوقت نفسه متغير تقني يجب ضبطه

تزامن الساعة، المنطقة الزمنية، daylight-saving changes، والسفر بين البلدان يمكن أن تغير تعريف اليوم والليل وتوقيت الدواء والنوم. خزّن timestamps أصلية وtimezone أو offset، وحدد قاعدة day boundary. لا تحول كل شيء إلى local time وتفقد الأصل. إذا أعاد الجهاز ضبط الساعة بعد sync، يجب أن تكون pipeline قادرة على كشف القفزات. في endpoints تعتمد على circadian patterns أو sleep، خطأ ساعة واحدة ليس تفصيلًا شكليًا؛ قد يغيّر night window والتلخيص.

15. firmware update قد يغير القياس من دون أن ترى ذلك

بعض الأجهزة تحدث firmware تلقائيًا، وقد يتغير filtering أو sensor behavior أو battery management. يجب أن تعرف سياسة vendor للتحديث، وهل يمكن تجميد النسخة أو على الأقل تسجيلها. اربط كل data segment بـfirmware version وdevice model. إذا حدث تحديث أثناء الدراسة اختبر discontinuity في measures، وقارن فترة قبل وبعد عندما يكون ذلك ممكنًا. لا تفترض أن نفس اسم المنتج يعني نفس measurement system طوال سنتين.

16. algorithm version جزء من تعريف endpoint

إذا أعدت vendor حساب step count بخوارزمية جديدة، فقد تتغير النتائج القديمة من الإشارة نفسها. لذلك endpoint يجب أن تشير إلى algorithm identifier/version والمعاملات المستخدمة. جمد نسخة التحليل الأساسية قبل database lock، ولا تسمح بتحديث silent في cloud dashboard. إذا احتجت algorithm أحدث، أنشئ derived dataset جديدة وأعد validation المناسبة، ثم نفذ bridge analysis يوضح أثر التغيير. هذه الممارسة تجعل التحديث العلمي ممكنًا من دون طمس تاريخ النتائج.

version pinning أهم من اسم العلامة التجارية

كتابة استخدمنا جهاز X لا تكفي لإعادة الدراسة. يلزم hardware revision وfirmware وapp version وalgorithm release وconfiguration. هذه الحزمة هي measurement stack الفعلية.

17. تبديل الجهاز يحتاج bridge لا تبديلًا صامتًا

قد ينكسر الجهاز أو يتوقف تصنيعه أو يضطر المشارك إلى استبداله. إذا كان البديل من model مختلف، اجمع فترة overlap على مجموعة من المشاركين أو bench/validation data مناسبة لتقدير comparability. لا تدمج القيم القديمة والجديدة مباشرة إذا كان systematic bias محتملًا. سجّل replacement date والسبب، وقرر مسبقًا هل analysis ستستخدم calibration equation أو stratification أو sensitivity exclusion. في مرض فائق الندرة قد لا تملك عينة كبيرة للbridge، لذا الأفضل اختيار ecosystem لها استقرار ودعم طويل الأمد منذ البداية.

18. sensor drift يحتاج مراقبة مستمرة

بعض sensors تنحرف مع الزمن أو الاستخدام أو درجة الحرارة. ضع QC checks تكشف baseline shifts أو clipping أو saturation أو قيم مستحيلة. استخدم calibration procedures إن كانت متاحة، وسجّل تاريخها ونتيجتها. لا تفترض أن device اجتازت verification مرة واحدة ستظل بنفس الأداء لسنوات. إذا كان endpoint حساسًا لتغير صغير، فإن drift تقني قد يشبه تغيرًا مرضيًا. plots على مستوى الجهاز والbatch تساعد على اكتشاف أنماط لا تظهر في المتوسط السريري.

19. BYOD تقلل اللوجستيات لكنها تزيد heterogeneity

استخدام هاتف أو ساعة يملكها المشارك قد يقلل الكلفة والعبء، لكنه يجلب models وأنظمة تشغيل وإعدادات مختلفة. قبل BYOD اسأل هل measure تعتمد على sensor characteristics موحدة أم يمكن للخوارزمية التعامل مع اختلاف hardware. ضع قائمة compatibility، اختبر versions الرئيسية، وسجل device metadata. إذا كانت الدراسة تحتاج endpoint عالية الدقة فقد يكون provisioned device أكثر دفاعًا. يمكن استخدام تصميم هجين، لكن يجب أن تكون comparability جزءًا من validation لا افتراضًا.

20. participant burden عامل قياس لا عامل راحة فقط

الشحن اليومي، إزالة الجهاز للاستحمام، tight strap، تطبيق يحتاج login متكرر، أو upload بطيء يمكن أن يخفض adherence بصورة مرتبطة بالعمر أو الإعاقة. قيّم burden في pilot وشارك المرضى في اختيار location وschedule. اجمع عدد التفاعلات المطلوبة والوقت والشكاوى والانقطاعات. endpoint تملك خصائص قياس ممتازة في المختبر لكنها تنتج 40% بيانات صالحة في المنزل ليست fit-for-purpose. تقليل العبء يحسن الجودة ويقلل selection bias لأن المشاركين الأقل قدرة على التعامل مع التقنية لن يُستبعدوا عمليًا.

21. accessibility يجب اختبارها ضمن population الحقيقية

اضطراب الرؤية أو المهارات الحركية الدقيقة أو cognition أو الحساسية اللمسية قد يجعل إعداد الجهاز صعبًا. لا تعتمد على usability testing مع موظفين أصحاء. اختبر pairing والشحن ووضع الجهاز ورسائل التطبيق مع المرضى أو مقدمي الرعاية. وفر caregiver mode عند الحاجة، وقلل الحاجة إلى نصوص صغيرة أو gestures دقيقة. إذا كان الدعم الأسري شرطًا غير معلن لاستعمال الجهاز، سجله لأنه قد يحد generalizability.

22. free-living measure ليست نسخة منزلية من اختبار العيادة

سرعة المشي في ممر محدد تقيس capacity تحت شروط منظمة، بينما wearable في الحياة اليومية قد تقيس performance الفعلية المتأثرة بالبيئة والدافع والمساعدة. الاثنين مرتبطان لكنهما ليسا متطابقين. لا تعتبر اختلافهما خطأ تلقائيًا؛ قد يكون هو القيمة العلمية المطلوبة. حدد هل construct المستهدفة القدرة القصوى أم النشاط الواقعي. استخدم structured tasks لتقييم analytical validity، ثم free-living data لاختبار clinical meaning وسلوك measure في الحياة اليومية.

23. البيئة اليومية confounder حقيقي

الطقس، المدرسة، العمل، عطلة نهاية الأسبوع، رمضان، السفر، العدوى الموسمية، والمساحة السكنية قد تغير النشاط والنوم من دون تغير في المرض. خزّن calendar context الضروري ولا تجمع بيانات شخصية أكثر مما تحتاج. عند التحليل افحص seasonality وweekday effects والتغيرات الكبرى في routine. في multi-country study قد تختلف هذه الأنماط بين المواقع، لذلك comparison خام لمتوسط الخطوات قد يعكس البيئة أكثر من phenotype. design طويل بما يكفي وwindows ممثلة يمكن أن يقللا أثر الأيام الاستثنائية.

24. aggregation window جزء من endpoint

متوسط يوم واحد، median أسبوع، أفضل ثلاث ساعات، أو 95th percentile ليست تلخيصات متكافئة. اختر window بناء على construct وسرعة التغير والضوضاء داخل الشخص. إذا كان المرض يؤثر في القدرة على sustained activity فقد يكون توزيع النشاط أهم من المتوسط. اختبر test-retest reliability لكل window، وحدد مسبقًا عدد الأيام الصالحة المطلوبة. لا تغير window بعد رؤية الفصل الأفضل بين المجموعات. خزّن rule code أو configuration حتى يمكن إعادة حساب endpoint من derived daily measures.

25. baseline الشخصي قد يكشف تغيرًا لا يظهر في المتوسط السكاني

في الأمراض النادرة شديدة heterogeneity قد يكون لكل مريض مستوى وظيفي مختلف جذريًا. قياسات متكررة قبل intervention أو خلال فترة مستقرة يمكن أن تبني individual baseline وتسمح بقياس deviation الشخصي. لكن لا تحول كل تغير شخصي إلى benefit؛ تحتاج معرفة variability الطبيعية وregression to the mean. استخدم baseline window كافية، وافحص stability، واحتفظ بتحليل population-level موازٍ. في N-of-1 أو individualized therapy تصبح هذه النقطة مركزية، لكن تفسيرها يحتاج pre-specified rules.

26. supportive care والأدوية أحداث متداخلة

تغير العلاج الطبيعي أو جهاز الحركة أو جرعة دواء أو جراحة قد يغير digital measure حتى إذا لم يتغير المرض الأساسي بالطريقة نفسها. سجّل exposures المهمة وتوقيتها، وحدد في estimand كيف ستتعامل معها. لا تحاول تنظيف signal بحذف كل فترة بعد أي تدخل؛ ذلك قد يجيب سؤالًا آخر. في natural history الهدف أحيانًا وصف المسار تحت الرعاية الواقعية، وفي تجربة قد تريد فصل effect محددة. يجب أن يتطابق التعامل التحليلي مع السؤال لا مع الرغبة في curve أبسط.

27. threshold للإشعار ليست endpoint تلقائيًا

قد يستخدم التطبيق threshold لإرسال إشعار عند انخفاض النشاط أو تسارع النبض، لكن rule التشغيلية ليست بالضرورة clinically validated endpoint. thresholds قد تُضبط للحساسية والسلامة أو لتقليل false alerts. إذا أردت استخدامها كoutcome بحثية تحتاج تعريفًا وتحققًا ومعنى مستقلًا. افصل monitoring logic من analysis endpoints حتى لا يتغير البروتوكول كلما عدّل vendor notification algorithm.

28. QC dashboard يجب أن يرى التقنية قبل أن يرى النتيجة

أنشئ لوحة جودة يومية أو أسبوعية تعرض data latency وwear time وbattery failures وsync failures وdevice replacements وfirmware distribution وoutlier sensors وmissingness حسب الموقع والمشارك. الهدف كشف مشكلة تشغيلية قبل أن تصبح dataset كاملة غير قابلة للاستخدام. لا تعرض clinical outcome للفرق بطريقة قد تؤثر في سلوك القياس إذا كان ذلك يهدد blinding، لكن اعرض مؤشرات التقنية. عرّف alert thresholds للـQC ومسار resolution مع timestamp وowner.

29. vendor lock-in خطر علمي لا تجاري فقط

إذا كانت البيانات لا تخرج إلا عبر dashboard مغلقة أو API غير مضمونة، فقد لا تستطيع إعادة التحليل بعد انتهاء العقد. اطلب export specification، raw أو minimally processed data، data dictionary، version history، rate limits، وسياسة retention. افهم حقوق استخدام الخوارزمية والمخرجات في البحث والنشر. إذا تغيرت الشركة أو أوقفت الخدمة يجب أن تظل لديك القدرة على تفسير releases المنشورة. portability جزء من reproducibility، خصوصًا في natural history تمتد سنوات.

30. data minimization مهمة حتى لو كانت sensor قادرة على جمع كل شيء

وجود GPS أو microphone أو raw location لا يعني أنك تحتاجها. اجمع فقط الإشارات اللازمة للmeasure وسياقها، وافصل identifiers عن stream التحليلية. إذا احتجت location context فاستخدم granularity أقل عندما تكفي، مثل indoor/outdoor أو region بدل مسار دقيق. raw sensor combinations قد تكشف routine أو أماكن حساسة، لذلك يجب أن يشمل privacy review metadata أيضًا. وضح للمشارك ما يُجمع وما لا يُجمع، ومن يستطيع الوصول، ومدة الاحتفاظ.

الخصوصية تدخل اختيار الجهاز منذ البداية

قد يكون جهاز ممتاز هندسيًا لكنه يفرض cloud flow لا يتوافق مع consent أو متطلبات المؤسسة. privacy architecture ليست خطوة بعد الشراء؛ هي أحد معايير fit-for-purpose.

31. security lifecycle أطول من فترة التجنيد

خطط لإنشاء الحسابات، recovery، revocation، device loss، انتهاء الدراسة، وحذف أو أرشفة البيانات وفق السياسة. لا تستخدم passwords مشتركة بين المشاركين ولا تبق accounts نشطة بعد الحاجة. افصل study identifier عن اسم الشخص قدر الإمكان. حدّث dependencies والتطبيقات بطريقة لا تغير algorithm التحليلية بلا توثيق. incident response يجب أن يعرف من يوقف sync ومن يخطر الفريق وكيف يحافظ على evidence التقنية من دون تعريض بيانات إضافية.

32. provenance يجب أن يصل من الرقم النهائي إلى sensor

لكل endpoint value مهمة يجب أن تستطيع معرفة participant pseudonym، الجهاز، firmware، raw files أو hashes، preprocessing، wear-time rules، algorithm version، parameters، aggregation window، timezone rules، وanalysis code release. هذه lineage تسمح بتصحيح خطأ لاحقًا من دون فقد الثقة في كل الدراسة. إذا كانت الخوارزمية cloud-only، احصل على release identifier وتوثيق كافٍ. اجعل provenance machine-readable قدر الإمكان بدل تجميعها بعد النشر من رسائل البريد.

33. definition table تمنع اختلاف فرق التحليل

أنشئ جدولًا لكل digital endpoint يحتوي الاسم، construct، unit، device configuration، eligible periods، minimum wear، preprocessing، aggregation، intercurrent event strategy، missingness rule، software version، وexpected range. هذا الجدول هو contract بين الفريق السريري والهندسي والإحصائي. إذا تغير أي عنصر افتح version جديدة. لا تعتمد على notebook واحد لفهم endpoint لأن المعرفة ستضيع عند انتقال المحلل.

34. sensitivity analysis يجب أن تتحدى pipeline نفسها

اختبر كيف تتغير النتائج إذا رفعت minimum wear، استخدمت window أخرى، استبعدت أيام المرض الحاد، قيدت analysis إلى firmware واحدة، أو طبقت algorithm release بديلة موثقة. إذا انقلب الاستنتاج بسبب تغيير معقول في preprocessing، فهذا جزء مهم من uncertainty. لا تستخدم sensitivity analyses لاختيار pipeline المفضلة بعد رؤية النتيجة؛ حدّد المخاطر مسبقًا بناء على measurement model وpilot.

35. multi-country harmonization تتطلب أكثر من شحن نفس الجهاز

حتى مع hardware موحدة قد تختلف الهواتف وشبكات البيانات والتوقيتات والروتين اليومي واللغة والدعم الفني. اختبر onboarding في كل موقع، وحدد offline buffering وسياسة sync، ووحدات القياس، وtimezone handling. إذا احتاج الجهاز smartphone محددًا فلا تفترض توفره. وفر support pathway لا يعتمد على لغة واحدة. metadata المحلية مثل holidays أو daylight saving قد تكون ضرورية لتفسير pattern. الهدف توحيد measurement chain مع السماح بسياق بيئي واضح.

36. acceptance test يجب أن يعيد بناء endpoint من الصفر

قبل تجميد الدراسة اختر participant وهميًا أو dataset اختبار، وابدأ من raw file أو المصدر الأقرب، ثم أعد preprocessing وnon-wear detection وfeature extraction وaggregation حتى endpoint النهائية. تحقق من hashes والversions والوحدات والتوقيت. نفذ test على جهاز مفقود ويوم ناقص وتبديل firmware وtimezone مختلفة، لا على happy path فقط. إذا احتاج analyst معلومة شفوية من vendor لإكمال pipeline فهناك gap توثيق يجب إغلاقها.

37. قائمة قبول قبل وصف digital endpoint بأنها fit-for-purpose

تحقق من أن concept مهم ومحدد؛ context of use مكتوبة؛ hardware verified؛ algorithm analytically validated في population المناسبة؛ clinical meaning مدعوم؛ wear time وnon-wear rules موثقة؛ missingness لها أسباب وتحليل؛ device وfirmware وalgorithm versions مثبتة؛ privacy وsecurity متناسبتان؛ participant burden مقبول؛ raw/derived data وprovenance قابلة للاسترجاع؛ aggregation والendpoint definitions ثابتة؛ sensitivity analyses محددة؛ وخطة replacement وvendor exit موجودة. إذا فشل عنصر حرج، لا تخفِه خلف كلمة wearable validated؛ صف maturity الحالية والعمل المطلوب.