تست نرم‌افزار سلامت؛ از Hazard تا Workflow و Evidence

در یک تست یکپارچه‌سازی، هر شش پیام سفارش بدون خطای HTTP تحویل می‌شوند، صف خالی است و داشبورد سبز می‌ماند؛ اما سامانه دو بیمار هم‌نام را یک نفر فرض می‌کند و یک نسخه قدیمی، سفارشی را که قبلاً متوقف شده دوباره Active نشان می‌دهد. این سناریوی ساختگی نشان می‌دهد تست نرم‌افزار سلامت با «API پاسخ داد» یا «صف پیام خالی شد» تمام نمی‌شود. شواهد باید نشان دهند اطلاعات درست، برای بیمار و Encounter درست، در مرحله درست Workflow و با نسخه و معنای درست نمایش و پردازش شده است.

این راهنما برای QA، توسعه، تحلیل کسب‌وکار، تیم محصول، عملیات و متخصصان دامنه نوشته شده است. از تعیین Intended Use و مرز سامانه شروع می‌کنیم؛ سپس Hazard، Clinical Workflow، هویت بیمار، سفارش و نتیجه، FHIR/HL7، DICOM، Terminology، کاربردپذیری، Downtime، بازیابی، Release Gate و Evidence Pack را به یک برنامه قابل اجرا وصل می‌کنیم.

مرز ایمنی و مقررات: این مقاله آموزش تست نرم‌افزار است، نه توصیه پزشکی، حقوقی یا مقرراتی. QA با تست، برای Scope و Build مشخص شواهد تولید می‌کند؛ ایمنی بیمار، اثربخشی بالینی یا انطباق سازمان را تضمین و گواهی نمی‌کند. طبقه‌بندی محصول، حوزه قضایی، Intended Use، الزامات قانونی، استاندارد لازم، پذیرش ریسک و تصمیم بالینی باید توسط صاحبان صلاحیت همان سازمان تعیین و نسخه‌دار شوند.

خلاصه عملی تست نرم‌افزار سلامت

پرسش	شاهد ضعیف	شاهد مفیدتر
آیا Interface کار می‌کند؟	همه پیام‌ها HTTP ۲۰۰ گرفتند	پیام، هویت، نسخه، Terminology و Transition صحیح را در مقصد ایجاد کرد و Reconciliation اختلافی ندارد
آیا Workflow امن‌تر است؟	Happy Path سبز است	Hazardهای مصوب به Requirement، Control، Test و Residual Risk قابل‌ردگیری‌اند
آیا سامانه FHIR است؟	JSON parse می‌شود	نسخه، Profile/IG، Cardinality، Binding، Reference، Authorization و رفتار End-to-End آزموده شده‌اند
آیا DICOM سازگار است؟	یک تصویر باز شد	Conformance Statement دو طرف، SOP/Role/Transfer Syntax و Workflow واقعی با داده آزمون تطبیق یافته‌اند
آیا Release آماده است؟	Pass rate بالا است	Critical Hazardها پوشش دارند، Unknown و Defect باز روشن‌اند، Downtime/Rollback آزموده و تصمیم امضاشده است

اول Scope را تعیین کنید: هر نرم‌افزار سلامت یک چیز نیست

عبارت Health IT می‌تواند پرونده الکترونیکی، HIS، پذیرش، نوبت‌دهی، نسخه و سفارش، آزمایشگاه، تصویربرداری، Telemedicine، صورتحساب، داشبورد مدیریتی، پژوهش، ابزار بیمار یا یک کارکرد نرم‌افزاری در وسیله پزشکی را پوشش دهد. پیامد Failure، Oracle، نقش متخصص بالینی و مسیر مقرراتی این محصولات یکسان نیست.

نوع کارکرد	پرسش Scope	تمرکز نمونه تست	مالک تصمیم
اداری/مالی	آیا خروجی مستقیماً در تصمیم یا مراقبت بالینی استفاده می‌شود؟	هویت، مبلغ، پوشش، صف، دسترسی و Audit	محصول، عملیات، مالی و حقوقی
EHR/HIS و Workflow بالینی	کدام نقش در چه زمان به کدام داده تکیه می‌کند؟	Patient context، سفارش، نتیجه، هشدار، handoff و downtime	Clinical safety، مالک فرایند و محصول
Device Software Function	آیا کارکرد طبق قانون حوزه هدف، Device محسوب می‌شود؟	Intended Use، Hazard، V&V، Traceability و مستندات مقرر	Regulatory، Quality و مهندسی دامنه
پژوهش/آموزش	آیا خروجی با برچسب مناسب از مسیر مراقبت جدا است؟	جداسازی محیط، provenance، دسترسی و منع استفاده ناخواسته	پژوهش، اخلاق، حقوقی و داده
Wellness/Consumer	Claim واقعی محصول چیست و کاربر چگونه آن را تفسیر می‌کند؟	Claim، داده ورودی، محدودیت، UI و escalation	محصول، پزشکی، حقوقی و Regulatory

راهنمای ۲۰۲۳ FDA درباره محتوای Premarket برای Device Software Functions صریحاً به کارکردهایی مربوط است که تعریف Device را برآورده می‌کنند و برای مستندات از رویکرد مبتنی بر ریسک استفاده می‌کند. آن را نباید خودکار به هر اپ سلامت، هر کشور یا هر نرم‌افزار اداری تعمیم داد. تیم باید Applicability Matrix داشته باشد، نه فهرستی از نام استانداردها.

تست چه چیزی را اثبات می‌کند و چه چیزی را نه؟

یک Test Run معتبر می‌تواند بگوید: «در Build، Config، داده، نقش، دستگاه، زمان و محیط ثبت‌شده، رفتار مشاهده‌شده با Oracle نسخه X مطابق بود.» همین گزاره نیز محدودیت دارد: مسیرهای اجرا‌نشده، خطای مدل، داده واقعی متفاوت، تغییر Configuration، رفتار کاربر و Failureهای مرکب ممکن است باقی بمانند.

• Pass شدن تست، ایمنی بیمار یا اثربخشی بالینی را تضمین نمی‌کند.
• نبود Defect گزارش‌شده، نبود Hazard یا Risk نیست.
• Conformance فنی، به‌تنهایی Interoperability معنایی و Workflow صحیح را ثابت نمی‌کند.
• اسکن امنیتی، انطباق Privacy یا صلاحیت استفاده بالینی را گواهی نمی‌کند.
• تأیید متخصص دامنه جای Verification نرم‌افزار را نمی‌گیرد و برعکس.
• Release Gate یک تصمیم سازمانی مبتنی بر Evidence و Residual Risk است، نه خروجی خودکار درصد Pass.

برای تبدیل مقرره یا استاندارد نسخه‌دار به Testable Requirement، از راهنمای تست انطباق استفاده کنید. این مقاله بر Workflow سلامت و Safety Evidence تمرکز دارد، نه تفسیر حقوقی چارچوب‌ها.

مدل Assurance: از Claim تا شواهد و ریسک باقی‌مانده

به‌جای شروع از Test Case، زنجیره Assurance را بسازید. Claim باید محدود، قابل رد و متعلق به یک Scope باشد. برای مثال «کاربر مجاز در Workflow W می‌تواند نتیجه تأییدشده بیمار P را با منبع و زمان درست ببیند» بسیار آزمون‌پذیرتر از «سامانه نتایج را امن نشان می‌دهد» است.

Intended Use / Context
        ↓
Hazard → Safety Requirement → Control
        ↓                    ↓
Verification + Validation + Human/Clinical Review
        ↓
Evidence + Limitation + Open Defect + Unknown
        ↓
Residual Risk → Authorized Release Decision → Production Monitoring

جزء	پرسش کنترل	نمونه Artifact
Claim	دقیقاً چه رفتار یا ویژگی ادعا می‌شود؟	Claim ID، Scope، Actor، Outcome، Exclusion
Hazard	چه منبع بالقوه آسیبی وجود دارد؟	Hazard log و Scenario
Control	ریسک چگونه حذف، کاهش یا آشکار می‌شود؟	Design control، alert، reconciliation، training
Evidence	کدام شاهد نشان می‌دهد Control در Scope کار کرده؟	Review، unit، integration، simulation، usability run
Limitation	شاهد چه چیزی را پوشش نمی‌دهد؟	Excluded cohort، device، workflow، uncertainty
Decision	چه کسی با کدام ریسک باقی‌مانده تصمیم می‌گیرد؟	Release memo و approval

Intended Use و System Context را نسخه‌دار کنید

یک تغییر کوچک متن، Feature Flag یا Mapping می‌تواند Intended Use عملی را تغییر دهد. بنابراین هر Run باید نه فقط Commit، بلکه نسخه Claim، Config، Terminology، Rule library و Interface contract را ثبت کند.

Health IT Context Contract
Product/Function:       [نام و نسخه]
Intended user:          [نقش، آموزش و مجوز]
Intended use:           [کار و تصمیم مورد پشتیبانی]
Patient/population:     [دامنه مصوب]
Care setting:           [کلینیک/بیمارستان/خانه/...]
Workflow boundary:      [شروع، پایان، handoff]
Inputs/sources:         [مالک و provenance]
Outputs/consumers:      [انسان/سیستم و اقدام ممکن]
Excluded use:           [موارد منع یا خارج Scope]
Failure consequences:  [برای چه کسی و چگونه]
Jurisdiction/class:     [تصمیم Regulatory نسخه‌دار]
Build/config/data:      [شناسه‌های immutable]
Decision owners:        [Clinical/Product/Quality/Regulatory]

Clinical Workflow را پیش از UI مدل کنید

صفحه Login→Form→Submit برای Health IT مدل کافی نیست. مسیر واقعی می‌تواند از پذیرش و شناسایی بیمار به Encounter، سفارش، جمع‌آوری نمونه، انجام، تأیید، مشاهده، اطلاع‌رسانی، اقدام و Follow-up برسد. هر مرحله Actor، پیش‌شرط، deadline، handoff، منبع حقیقت و حالت استثنا دارد.

مرحله	Actor	شناسه‌های حیاتی	Failure نمونه	Evidence نمونه
ثبت/پذیرش	پذیرش یا بیمار	Patient، encounter	Duplicate یا Merge اشتباه	Matching/Unmerge و audit
سفارش	کاربر مجاز	Patient، encounter، order	سفارش در Context بیمار دیگر	Context banner، authorization و state test
انجام/نمونه	بخش اجرا	Order، specimen، device	برچسب یا association اشتباه	Barcode/synthetic identity chain
نتیجه/تأیید	نقش تأییدکننده	Result، version، provenance	Draft به‌عنوان Final	State/role/version assertions
مشاهده/پیگیری	تیم مراقبت یا بیمار	Result، recipient، message	نتیجه دیده نشود یا برای فرد غلط ارسال شود	Delivery≠review؛ acknowledgment/escalation
Downtime/بازگشت	همه نقش‌های در Scope	Offline record، reconciliation ID	دوباره‌کاری یا از دست‌رفتن اقدام	Restore و reconciliation rehearsal

راهنماهای SAFER سال ۲۰۲۵ دفتر ONC نیز ایمنی EHR را فقط مسئله نرم‌افزار نمی‌بینند: مدیریت سیستم، برنامه‌ریزی قطعی، شناسایی بیمار، سفارش و پشتیبانی تصمیم، گزارش نتیجه و ارتباط تیم درمان هر کدام فرایند و مسئولیت سازمانی دارند. این راهنماها برای Self-assessment هستند و جای مقررات یا روش مصوب محصول شما را نمی‌گیرند.

از Hazard به Scenario قابل تست برسید

Hazard را با Defect یکی نگیرید. Defect علت یا شرایطی در پیاده‌سازی است؛ Hazard منبع بالقوه آسیب است؛ Hazardous Situation شرایط مواجهه با آن و Harm پیامد واقعی یا بالقوه برای فرد است. روش دقیق باید با استاندارد و فرایند مصوب دامنه هماهنگ شود، اما QA برای طراحی تست به زنجیره علت و Control نیاز دارد.

Hazard Scenario
ID: H-___
Context/actor: [کجا و چه کسی]
Sequence:      [رخدادها و وابستگی‌ها]
Hazard:        [منبع بالقوه آسیب]
Situation:     [شرایط مواجهه]
Possible harm: [بدون ادعای احتمال پزشکی]
Control(s):    [طراحی/آشکارسازی/فرایند]
Test oracle:   [رفتار قابل مشاهده]
Evidence:      [روش، داده، محیط]
Residual risk: [مالک، تصمیم و بازبینی]

تست مبتنی بر ریسک برای اولویت‌بندی مفید است، به‌شرط آنکه ماتریس رنگی جای تحلیل تخصصی را نگیرد. راهنمای RBT تفاوت Product Risk، Project Risk و Residual Risk و نحوه نگاشت آن‌ها به Evidence را توضیح می‌دهد.

Clinical Claim و Test Oracle را جدا کنید

QA نباید محتوای پزشکی را از اینترنت یا تجربه شخصی به Expected Result تبدیل کند. «این هشدار باید نمایش داده شود» تنها وقتی Oracle معتبر است که Rule، نسخه، شرایط، منبع، Owner و Approval آن مشخص باشد. نرم‌افزار می‌تواند Rule تأییدشده را درست اجرا کند، در حالی که اعتبار بالینی خود Rule پرسشی جدا برای متخصص و فرایند مربوط است.

لایه Oracle	نمونه پرسش	مالک معمول
محاسبات نرم‌افزار	برای Fixture مصوب، خروجی دقیق و واحد چیست؟	مهندسی + QA
Rule/Content	کدام Rule set و نسخه باید اعمال شود؟	Clinical content owner
Workflow	چه کسی، در چه مرحله و با چه acknowledgment اقدام می‌کند؟	مالک فرایند بالینی
Human factors	کاربر هدف پیام را می‌بیند، می‌فهمد و اقدام مورد انتظار را انجام می‌دهد؟	Human factors/UX + نقش هدف
Regulatory claim	آیا Claim و Evidence در Scope مجاز و کافی‌اند؟	Regulatory/Quality

Traceability را دوطرفه و تغییرپذیر بسازید

Traceability فقط جدول Requirement→Test نیست. باید بتوان از Hazard به Control و Evidence رفت و از هر تست نیز فهمید کدام Claim یا Risk را پوشش می‌دهد. مسیر معکوس Test→Requirement مانع Testهای یتیم و مسیر Hazard→Evidence مانع Riskهای بدون شاهد می‌شود.

Hazard ID	Requirement/Control	Evidence method	Build/Data	نتیجه	محدودیت/ریسک باقی‌مانده
H-ID-01	نمایش Patient context ثابت هنگام سفارش	Scenario + observation	B42/SYN-07	Pass	تبلت قدیمی اجرا نشده
H-ORD-02	نسخه قدیمی state را عقب نبرد	Duplicate/reorder injection	B42/ORD-v1	Pass	Vendor Z خارج Scope
H-DOWN-03	رکوردهای Offline reconcile شوند	Downtime rehearsal	B42/DR-03	Blocked	ریسک نامعلوم؛ Gate باز نمی‌شود

وقتی Requirement، Rule library یا Interface Profile تغییر می‌کند، Impact analysis باید Testها، Migration، Documentation، Training، Monitoring و Rollback مرتبط را پیدا کند. «کد این Component تغییر نکرده» دلیل کافی برای حذف Regression نیست.

هویت بیمار، Encounter و Context را یک رشته نام نبینید

نام نمایشی، شماره تلفن یا شماره تخت کلید هویت نیست. Patient، Encounter، Order، Specimen، Result، Practitioner، Location و Device شناسه و چرخه عمر مستقل دارند. Test data باید Collision، Merge/Unmerge، Alias، تغییر مشخصات، ثبت تکراری، نوزاد یا فرد بدون شناسه معمول، انتقال بخش و چند Encounter هم‌زمان را متناسب با Scope پوشش دهد.

• Patient banner در همه صفحات و Modalهای تصمیم‌ساز ثابت و قابل تمایز است.
• بازکردن Tab دوم یا Back/Forward، Context پنهانی را عوض نمی‌کند.
• Session timeout و Re-authentication، Draft را به بیمار دیگری وصل نمی‌کند.
• Search fuzzy، دو فرد با نام یا تاریخ مشابه را خودکار Merge نمی‌کند.
• Merge و Unmerge، History، Audit، order/result link و downstreamها را سازگار نگه می‌دارند.
• Print، Export، Notification و Cache نیز همان Patient/Encounter را حفظ می‌کنند.
• ورود فارسی، عربی و لاتین، «ی/ی»، «ک/ک»، فاصله و نیم‌فاصله باعث Collision خاموش نمی‌شود.

آزمون باید هم False Match و هم Missed Match را ببیند. بهینه‌سازی یک معیار می‌تواند دیگری را بدتر کند؛ Threshold یا الگوریتم matching را QA به‌تنهایی تعیین نمی‌کند و نتیجه روی داده مصنوعی، عملکرد در جمعیت واقعی را ثابت نمی‌کند.

سفارش، وضعیت و Clinical Decision Support را State Machine کنید

سفارش یک ردیف CRUD نیست. Draft، Signed، Active، On-hold، Modified، Discontinued، Completed، Corrected و Entered-in-error ممکن است معنا و transitionهای مجاز متفاوت داشته باشند. نام و تعداد Stateها باید از Contract محصول بیاید؛ مثال زیر نسخه عمومی یا پزشکی نیست.

Order State Contract
Entity key:       patientId + encounterId + orderId
Version rule:     only greater version changes current state
Duplicate rule:   same entity + version = no-op + audit
Late rule:        lower version = historical, never current
Actor/role:       permitted transitions per approved matrix
Reason:           required for selected transitions
Downstream:       event, acknowledgment and reconciliation
Display:          current state + source + time + author
Failure handling: retry without duplicate effect; quarantine on ambiguity

برای Alert یا CDS، فقط ظاهرشدن Popup را تست نکنید. eligibility، داده ناقص، زمان Rule، duplicate suppression، severity مصوب، override reason، attribution، audit، silent failure، unavailable dependency و update/rollback کتابخانه Rule را بسنجید. نرخ Override به‌تنهایی اثبات «هشدار بد» یا «کاربر بی‌دقت» نیست؛ Context و مطالعه انسانی لازم است.

نتیجه، نسخه، Provenance و Follow-up را End-to-End بسنجید

وجود Result در Database کافی نیست. Draft نباید Final دیده شود؛ Correction باید نسخه قبلی را قابل‌ردگیری کند؛ منبع، زمان، واحد، محدوده یا flag مصوب باید با نسخه داده همراه باشند؛ گیرنده درست باید به نسخه درست دسترسی داشته باشد؛ و اگر Workflow نیازمند acknowledgment یا escalation است، صرف ارسال Notification پایان کار نیست.

Scenario	تزریق	Invariant
نتیجه دیررس	Result بعد از بسته‌شدن Encounter می‌رسد	به Patient/Order صحیح متصل و وارد مسیر Follow-up می‌شود
Correction	نسخه Final اصلاح می‌شود	نسخه جدید Current، قبلی Historical و دریافت‌کنندگان لازم مطلع‌اند
Duplicate	پیام مشابه دوباره می‌رسد	اثر کسب‌وکاری تکرار نمی‌شود؛ دریافت Audit می‌شود
Partial outage	Notification unavailable است	Result گم یا Completed کاذب نمی‌شود؛ retry/escalation مشاهده‌پذیر است
Unauthorized view	نقش خارج Scope URL مستقیم را باز می‌کند	Access در server رد و رویداد مناسب ثبت می‌شود

Integration Testing در سلامت: انتقال، معنا و Workflow سه لایه‌اند

Interface ممکن است از نظر Transport سالم، از نظر Schema معتبر و از نظر بالینی یا Workflow اشتباه باشد. برنامه تست باید این لایه‌ها را جدا گزارش کند تا «HL7 passed» یا «DICOM supported» به Claim مبهم تبدیل نشود.

لایه	پرسش	Failure نمونه
Transport	پیام رسید، retry و acknowledgment درست بود؟	Timeout-after-commit باعث ارسال تکراری می‌شود
Syntax/Schema	ساختار با نسخه و Profile سازگار است؟	Cardinality یا نوع مقدار غلط است
Terminology	System/code/version/display و ValueSet درست‌اند؟	کد محلی به معنای دیگری Map می‌شود
Identity/Reference	Patient، encounter، order و result به موجودیت درست اشاره می‌کنند؟	Reference معتبر ولی مربوط به فرد دیگر است
Workflow	Transition، Actor و deadline درست‌اند؟	پیام قدیمی State را عقب می‌برد
Human use	اطلاعات لازم در زمان و Context مناسب قابل فهم است؟	کاربر نسخه اصلاح‌شده را از قبلی تشخیص نمی‌دهد

برای الگوهای Contract، Component و End-to-End، راهنمای تست یکپارچه‌سازی را ببینید؛ در Health IT باید آن الگوها را با Hazard و Workflow دامنه ترکیب کرد.

تست FHIR: Valid Resource پایان آزمون نیست

FHIR پایه‌ای برای تبادل است، اما Implementation Guide، Profile، CapabilityStatement، Terminology و قرارداد شرکای تبادل تعیین می‌کنند چه چیزی در Context شما لازم است. نسخه FHIR و Packageهای IG را pin کنید؛ Validation با Latest شناور، نتیجه امروز را فردا غیرقابل تکرار می‌کند.

• JSON/XML parse و نوع Resource؛
• Cardinality، invariant، slicing و fixed/pattern value؛
• Profile و package version دقیق؛
• Terminology binding با code system/value set/version؛
• Reference resolution، contained resource و identifier semantics؛
• Capability و interactionهای واقعی client/server؛
• Search parameter، pagination، history، conditional operation و concurrency در Scope؛
• Authorization، compartment، consent/policy و audit جدا از structural validation؛
• Business rule، duplicate، patient matching و workflow end-to-end؛
• Negative test برای malformed، unsupported، ambiguous و partial data.

صفحه رسمی FHIR Validation هشدار می‌دهد روش‌های اعتبارسنجی فقط جنبه‌های محاسبه‌پذیر Conformance را می‌سنجند؛ Business Ruleها و قواعد روایی یا انسانی می‌توانند بیرون آن بمانند و Static validation برای اثبات Conformance کامل کافی نیست. پس یک Resource سبز در Validator، هویت درست، مجوز درست یا Workflow درست را تضمین نمی‌کند.

FHIR Test Manifest
FHIR version:        [مثلاً R4، دقیق و pin شده]
IG/package/version:  [canonical + package hash]
Profile(s):          [canonical URLs]
Terminology server:  [version/config/snapshot]
Capability claim:    [client/server statement]
Fixture provenance:  [synthetic generator + seed]
Operations:          [create/read/search/update/...]
Business invariants: [identity/state/authorization]
Negative cases:      [unsupported/ambiguous/stale]
Validator output:    [artifact + warnings policy]
End-to-end evidence: 

HL7 v2 و پیام‌های رویدادی: ACK را با Outcome یکی نگیرید

در Interfaceهای پیام‌محور، ACK ممکن است تنها دریافت یا پذیرش اولیه را نشان دهد. برای هر Interface تعریف کنید ACK در کدام لایه صادر می‌شود، خطای parsing یا business validation چگونه بازمی‌گردد، retry چه کلیدی دارد، ترتیب چگونه مدیریت می‌شود و Reconciliation مستقل چگونه اختلاف مبدأ و مقصد را پیدا می‌کند.

حالت	تزریق	رفتار مورد انتظار قراردادی
Duplicate	همان message/event دوباره	No-op یا نتیجه idempotent، با audit
Out of order	نسخه ۲ پیش از ۱	Current state عقب نرود
Timeout after commit	مقصد ثبت کرده، پاسخ گم شده	Retry اثر دوم نسازد
Poison message	داده ساختاری معتبر اما معنایی نامعتبر	Quarantine، alert، no silent drop
Partial mapping	کد جدید در مقصد ناشناخته	Fail/hold صریح؛ default معنایی پنهان ممنوع
Clock skew	ساعت دو سیستم متفاوت	ترتیب به timestamp نامطمئن وابسته نباشد

تست DICOM: Conformance Statement نقطه شروع است

DICOM فقط «فایل تصویر» نیست. بسته به Workflow، SOP Class و نقش SCU/SCP، Transfer Syntax، Association، UID، metadata، worklist، storage commitment، query/retrieve، viewer behavior، display و ارتباط با Patient/Study/Series باید بررسی شوند. Scope را از Real-World Activity و Conformance Statement محصولات واقعی بگیرید.

بخش جاری DICOM PS3.۲ درباره Conformance می‌گوید Standard روش آزمون/اعتبارسنجی Implementation یا تطابق آن با Conformance Statement را تعیین نمی‌کند. قالب رسمی نیز یادآوری می‌کند DICOM به‌تنهایی Interoperability را تضمین نمی‌کند و مقایسه Statementها باید با اعتبارسنجی تجهیزات مشخص تکمیل شود.

ناحیه	نمونه بررسی	شاهد لازم
Negotiation	AE، Role، SOP، Transfer Syntax و failure status	Network trace + طرفین نسخه‌دار
Identity	Patient/Study/Series/SOP Instance UID و merge	Fixture chain + destination query
Metadata	Required/conditional attributes، charset، timezone	Dataset validation + viewer display
Pixel/display	orientation، windowing، grayscale/color و annotation در Scope	مرجع مصوب و review تخصصی؛ نه screenshot حدسی
Workflow	worklist، acquisition، store، commitment، report link	End-to-end rehearsal
Failure	قطع، retry، storage full، duplicate، partial series	recovery/reconciliation evidence

Terminology، واحد و زمان را داده نمایشی فرض نکنید

Code بدون System و Version می‌تواند مبهم باشد؛ Display متن مرجع معنا نیست؛ تبدیل واحد بدون dimensional rule و precision مصوب خطرناک است؛ و Local time بدون offset و timezone برای ترتیب رخداد کافی نیست. Test fixture باید Code system/version، ValueSet expansion، unit code، magnitude، precision، effective time، authored time، received time و timezone را صریح ثبت کند.

• کد معتبر اما خارج ValueSet مورد توافق؛
• کد Deprecated، replacement و نسخه قدیمی Terminology؛
• System درست با Display ترجمه‌شده یا اشتباه؛
• عدد بدون واحد، واحد ناشناخته و تفاوت مقیاس؛
• Decimal separator، رقم فارسی/عربی/لاتین و rounding؛
• UTC، Asia/Tehran، offset، DST تاریخی و تقویم نمایشی؛
• Future timestamp، clock skew و رویدادهای هم‌زمان؛
• عدم دسترسی Terminology service و رفتار fallback.

اگر محصول تاریخ شمسی نشان می‌دهد، مقدار canonical، timezone و قواعد تبدیل باید جدا باشند. نمایش ۱۴۰۵/۰۵/۲۱ نباید provenance زمان UTC یا offset را حذف کند. برای ارقام و متن فارسی نیز Normalize نمایشی را از Identity یا امضای داده جدا کنید.

Data Migration و Reconciliation را به Count محدود نکنید

برابری تعداد ردیف‌ها می‌تواند با Patient association غلط، version loss، code mapping ناقص یا حذف تاریخچه همراه باشد. Migration باید Snapshot و Delta، mapping version، reject/exception، referential integrity، semantic invariant، audit/provenance، rollback و reconciliation پس از Cutover را پوشش دهد.

کنترل	معیار ضعیف	معیار بهتر
Completeness	Count کل برابر	Count به تفکیک entity/state/time/slice + exception manifest
Identity	نام‌ها وجود دارند	Stable identifiers و reference graph درست‌اند
Semantics	fieldها پرند	Code/unit/version/state طبق mapping مصوب‌اند
History	Current value درست است	نسخه، author، time و correction chain حفظ شده‌اند
Cutover	Import success	Delta capture، freeze boundary و no double-write gap
Rollback	Backup داریم	Restore تمرین‌شده و reconciliation پس از برگشت

داده تست: Synthetic اولویت دارد، De-identification ادعا نیست

کپی Production و «حذف نام» راهبرد امن داده تست نیست. داده سلامت می‌تواند از ترکیب سن، زمان، مکان، رخداد نادر، تصویر، free text یا identifierهای جانبی دوباره نسبت داده شود. تعیین اینکه داده واقعاً anonymous، de-identified یا همچنان personal/sensitive است به روش، قانون و Context وابسته است و باید توسط Privacy/Legal تأیید شود.

گزینه	مزیت	ریسک/محدودیت	Control
Synthetic deterministic	تکرارپذیر و بدون بیمار واقعی	تنوع واقعی را کامل مدل نمی‌کند	Generator/seed/version + edge catalog
Hand-authored fixture	Oracle روشن برای Hazard خاص	کوچک و مستعد confirmation bias	Peer review + negative cases
De-identified extract	ساختار و توزیع واقعی‌تر	ریسک بازشناسایی و scope creep	روش مصوب، حداقل‌سازی، access/expiry/audit
Production data	بیشترین شباهت	ریسک بسیار بالا و اغلب ناموجه	فقط با تصمیم رسمی، ضرورت، safeguards و محیط مجاز

• هیچ نام، شناسه، تصویر، متن آزاد یا timestamp واقعی را در Ticket و Screenshot نریزید.
• Fixtureها را به‌وضوح SYNTHETIC و غیرقابل استفاده بالینی علامت بزنید.
• دامنه، owner، retention، access، export و destruction محیط تست را ثبت کنید.
• Telemetry و log تست نیز ممکن است داده حساس یا token بسازند.
• Generator را version و seed را ذخیره کنید تا Failure بازتولید شود.
• برای rare edgeها از متخصص دامنه سناریو بگیرید، نه داده واقعی.

Privacy و Security شرط لازم‌اند، اما مالکیت جدا دارند

داده درست برای بیمار درست اگر به نقش غیرمجاز نمایش داده شود همچنان Failure است. در مقابل، رمزنگاری کامل نمی‌تواند Patient matching یا State transition غلط را اصلاح کند. برنامه Health IT باید Threat، Privacy harm و Clinical hazard را در یک Context ببیند، اما آن‌ها را به یک checklist مبهم ادغام نکند.

• Authentication، session، MFA و recovery برای نقش‌های واقعی؛
• Authorization در server، نه پنهان‌کردن Button؛
• Break-glass با justification، alert، محدودیت و review؛
• Least privilege و separation of duties؛
• Audit با actor، subject، action، time، source و tamper controls؛
• Encryption/key/secret lifecycle و backup/export؛
• Tenant/organization isolation و indirect object reference؛
• Notification، print، clipboard، screenshot، cache و support tools؛
• Third-party، analytics و crash report data flow؛
• Incident response با پیوند به continuity و patient-impact assessment.

برای Threat model و آزمون کنترل‌ها، راهنمای تست امنیت نرم‌افزار و برای شمول، data flow، retention و حقوق اشخاص، راهنمای تست حریم خصوصی را به Plan این مقاله پیوند دهید. هیچ‌کدام به‌تنهایی Safety case نیستند.

Usability و Human Factors: درست‌بودن Backend کافی نیست

کاربر ممکن است اطلاعات درست را نبیند، Context را اشتباه تفسیر کند، به‌دلیل تراکم Alert از پیام عبور کند یا در فشار زمان دکمه نزدیک را انتخاب کند. تست باید کاربر هدف، کار واقعی، محیط، interruption، device، workload و consequence را بازنمایی کند. QA یا طراح نمی‌تواند صرفاً نقش پزشک، پرستار، تکنسین یا بیمار را بازی کند و Evidence نماینده تولید کند.

روش	پرسش	محدودیت
Expert review	آیا heuristic یا risk آشکار وجود دارد؟	رفتار کاربر هدف را ثابت نمی‌کند
Workflow walkthrough	Actorها و handoffها کجا می‌شکنند؟	محیط واقعی و فشار را کامل بازسازی نمی‌کند
Usability session	کاربر هدف Task تعریف‌شده را چگونه انجام می‌دهد؟	نمونه و سناریو محدود است
Simulation	تیم در interruption/failure چگونه هماهنگ می‌شود؟	نیازمند facilitation و safety protocol
Telemetry	در Production چه مسیر و خطایی دیده می‌شود؟	قصد، فهم و causality را به‌تنهایی نشان نمی‌دهد

راهنمای Usability Testing طراحی Study را پوشش می‌دهد و راهنمای معیارهای کاربردپذیری محدودیت Task Success، زمان و SUS را توضیح می‌دهد. در محصول سلامت، Study باید زیر نظر نقش‌های مناسب و با حفاظت شرکت‌کننده انجام شود؛ امتیاز رضایت به‌تنهایی شاهد ایمنی نیست.

ابهام «Sensitivity Testing» را رفع کنید

Sensitivity Testing در این حوزه می‌تواند دست‌کم چهار معنا داشته باشد: طبقه‌بندی حساسیت داده، حساسیت یک پارامتر در مدل، توان آشکارسازی یک سیستم اندازه‌گیری، یا معیار آماری/تشخیصی مانند sensitivity. این‌ها یک Test Type عمومی نیستند. در Test Plan دقیقاً Characteristic، تعریف، داده مرجع، روش، threshold، confidence و Owner را بنویسید.

• Data sensitivity: به Privacy classification و کنترل دسترسی مربوط است.
• Parameter sensitivity: تغییر کنترل‌شده ورودی و اثر بر خروجی مدل/محاسبه است.
• Analytical sensitivity: به روش، ابزار و مرجع تخصصی همان دامنه نیاز دارد.
• Clinical sensitivity/specificity: معیار آماری روی Reference و Population تعریف‌شده است و QA عمومی Threshold آن را تعیین نمی‌کند.

عبارت «سامانه بسیار حساس است» Oracle نیست. باید به گزاره‌ای مانند «با Fixture نسخه X و Reference مصوب، metric M با روش A محاسبه و interval/limitation گزارش می‌شود» تبدیل شود. این نتیجه نیز قابلیت تعمیم خارج Population و Protocol را ثابت نمی‌کند.

Performance را با Workload بالینی و Deadline معنا کنید

میانگین Response Time در بار یکنواخت کافی نیست. Workload باید شیفت، batch، burst، بازگشت پس از قطعی، concurrent editing، large study، گزارش‌گیری، backup، interface retry و slow dependency را مدل کند. SLO یا deadline را Owner فرایند و معماری بر اساس Context تعیین می‌کنند؛ QA عدد عمومی اختراع نمی‌کند.

Dimension	Fixture/Workload	Evidence	خطر Aggregate
Latency	Critical action به تفکیک role/journey	p50/p95/p99 + tail trace	میانگین tail را پنهان می‌کند
Throughput	burst و steady state	accepted/completed/backlog	accepted مساوی processed نیست
Freshness	source→destination→screen	end-to-end age	API سریع با داده stale
Capacity	storage/queue/thread/pool	saturation و headroom	CPU پایین با pool exhausted
Degradation	dependency slow/down	bounded queue، fallback، recovery	retry storm پنهان
Recovery	backlog پس از outage	catch-up time + reconciliation	normal-load test کافی نیست

Downtime را به‌عنوان Workflow جایگزین تست کنید

Downtime فقط صفحه «سرویس در دسترس نیست» نیست. باید معلوم باشد کدام کارها ادامه می‌یابند، چه داده‌ای در دسترس است، رکورد Offline چگونه هویت می‌گیرد، چه کسی اطلاع می‌دهد، تغییر به حالت جایگزین چگونه اعلام می‌شود و پس از بازگشت چه کسی اختلاف‌ها را reconcile می‌کند.

Downtime Exercise Card
Scenario:          [planned/unplanned/partial/cyber]
Unavailable scope: [component/interface/location]
Start signal:      [who declares, how communicated]
Fallback:          [approved workflow and forms]
Identity method:   [patient/encounter/order continuity]
Read-only data:    
Safety limits:     [what must stop or escalate]
Return criteria:   [health + data checks]
Reconciliation:    [owner, key, duplicate/conflict rules]
Exercise evidence: [timeline, observations, gaps, actions]

• قطع کامل و جزئی، نه فقط خاموشی برنامه اصلی؛
• وابستگی Identity، Terminology، Notification و چاپ؛
• Read-only cache با freshness و warning روشن؛
• ثبت کاغذی/Offline با شناسه قابل reconcile؛
• رویدادهای ساخته‌شده هم‌زمان در دو مسیر؛
• بازگشت مرحله‌ای، backlog، duplicate و conflict؛
• تمرین نقش انسانی، تماس و escalation؛
• ثبت action و آزمون effectiveness پس از Exercise.

برای طراحی Fault، steady state، recovery و محدودیت Chaos، راهنمای تست تاب‌آوری را ببینید. Fault injection در محیط سلامت بدون Scope، مجوز، Safety boundary و امکان توقف می‌تواند خود خطر ایجاد کند؛ تمرین باید در محیط و زمان مصوب انجام شود.

Backup، Restore و Reconciliation سه کنترل جدا هستند

موفقیت Job پشتیبان‌گیری ثابت نمی‌کند فایل قابل بازیابی، کامل، رمزگشایی‌پذیر یا سازگار با نسخه برنامه است. Restore نیز به‌تنهایی ثابت نمی‌کند داده‌های بین Recovery Point و بازگشت با رکوردهای Offline یا downstreamها reconciled شده‌اند.

مرحله	پرسش	شاهد
Backup	چه داده/config/key و با چه retention ثبت شد؟	manifest، checksum، encryption/key access
Restore	در محیط پاک و نسخه هدف بالا آمد؟	timed restore + integrity queries
Application validation	Workflow حیاتی با داده بازیابی‌شده کار می‌کند؟	critical smoke + identity/reference checks
Reconciliation	gap، duplicate و conflict چگونه حل شدند؟	difference report + owner decisions
Return	کدام شرط اجازه بازگشت می‌دهد؟	signed readiness + monitoring
Learning	Actionها واقعاً مؤثر شدند؟	owner/due/retest/closure evidence

Configuration و Rule Change را Release مستقل ببینید

بسیاری از تغییرات پراثر بدون Deploy کد رخ می‌دهند: Form، order set، alert، role matrix، unit map، terminology package، interface route، template، Feature Flag یا device configuration. هر تغییر باید Request، rationale، reviewer، version، affected scope، test evidence، effective time و rollback داشته باشد.

Release Identity
Code commit/image digest:  ___
Database schema/migration: ___
Clinical content version:  ___
Terminology/IG package:     ___
Role/permission matrix:     ___
Interface mapping/config:   ___
Feature flags:              ___
Device/client versions:     ___
Synthetic fixture/seed:     ___
Environment checksum:       ___
Evidence pack ID:           ___

Four-eyes review یا approval بدون اجرای Test کافی نیست؛ اجرای Test بدون تأیید محتوا نیز کافی نیست. جداسازی نقش‌ها باید متناسب با ریسک باشد و مسیر Emergency change با expiry، retrospective review و rollback روشن داشته باشد.

Release Gate را بر Hazard و Unknown بنا کنید

Pass rate خام می‌تواند صد تست UI کم‌ریسک را کنار یک Scenario حیاتی Blocked جمع کند. Gate باید به Claim/Hazard ID، Evidence freshness، محیط، Defect، Unknown، mitigation، rollback و monitoring متصل باشد.

وضعیت Evidence	تفسیر	رفتار Gate نمونه
Pass	در Scope و Oracle ثبت‌شده مطابق بود	Risk حذف نشده؛ limitation باقی می‌ماند
Fail	رفتار با Oracle ناسازگار بود	Contain/fix/retest یا acceptance مجاز
Blocked	پیش‌شرط/محیط/داده مانع اجرا شد	Unknown؛ به‌عنوان Pass یا Not applicable پنهان نشود
Inconclusive	شاهد یا Oracle برای نتیجه کافی نبود	تحقیق/روش بهتر؛ Gate طبق exposure
Not run	هیچ شاهد جدید تولید نشده	Risk exposure و دلیل صریح
Stale	Evidence به نسخه یا Config قبلی مربوط است	Impact analysis و revalidation

Health IT Release Memo
Scope and release identity:     ___
Clinical/operational claims:    ___
Critical hazards and evidence:  ___
Open defects and workarounds:   ___
Blocked/inconclusive/unknown:   ___
Downtime/restore/rollback:      ___
Monitoring and alert owners:    ___
Residual risk and limitations:  ___
Recommendation: Go / Conditional / Hold
Authorized decision and expiry: ___

Production Monitoring باید Claim را ببیند، نه فقط CPU را

Availability سبز می‌تواند با backlog، stale data، mismatch، dropped result یا rule version غلط همراه باشد. برای هر Claim مهم، observable signal، numerator/denominator، freshness، slice، threshold مصوب، owner، runbook و escalation تعریف کنید.

Signal	Counter-signal	Slice	اقدام
پیام accepted	processed/reconciled/age	interface، event type، site	queue trace و reconciliation
نتیجه ارسال شد	delivered/viewed/follow-up state	channel و workflow	retry/escalation طبق Contract
Alert نمایش داده شد	eligible/missed/override/unknown	rule version و role	content/system review
Login success	authorization denial/anomaly	role/site/client	security runbook
Restore job success	restore rehearsal age	dataset/site	exercise و action

Metric باید از داده حساس حداقل لازم را نگه دارد. Patient ID، متن بالینی یا payload کامل را برای مشاهده‌پذیری عمومی log نکنید. Correlation ID مصنوعی/کنترل‌شده، hashing با threat review، access محدود و retention مصوب به‌کار ببرید؛ تصمیم دقیق با Privacy/Security است.

Incident و Near Miss را به Regression Evidence تبدیل کنید

Incident فقط Ticket فنی نیست. ابتدا containment و مسیر پاسخ سازمانی انجام می‌شود؛ سپس Timeline با زمان‌های چندمنبعی، affected scope، version/config، patient/workflow impact ارزیابی‌شده توسط نقش مناسب، Controlهای ناکام، detection gap و recovery ثبت می‌شود. هدف تحلیل سیستم است، نه یافتن سریع یک فرد برای سرزنش.

• Artifact و log لازم را با مجوز و حداقل داده حفظ کنید.
• Known impact، potential exposure و unknown را از هم جدا کنید.
• Timeline را با timezone و clock uncertainty ثبت کنید.
• هر Action یک Owner، deadline، evidence و effectiveness check داشته باشد.
• Scenario به fixture مصنوعی و Regression test تبدیل شود.
• Monitoring gap و runbook نیز مثل code defect اصلاح شوند.
• Near miss و recovery موفق را برای فهم Controlهای مؤثر بررسی کنید.

Evidence Pack قابل ممیزی بسازید

Screenshot پراکنده یا لینک Pipeline که بعداً expire می‌شود Evidence Pack نیست. بسته باید immutable یا دست‌کم tamper-evident، قابل ردیابی، دارای retention و دسترسی مصوب و قابل بازتولید در حد روش باشد. داده حساس را فقط چون «مدرک تست» است بی‌حد نگه ندارید.

Evidence Pack Index
01 Context / Intended Use / Applicability decision
02 Hazard log and traceability matrix
03 Requirements, rules, profiles and approvals
04 Release identity and environment manifest
05 Synthetic fixture generator, seed and checksums
06 Test procedures, raw results and review records
07 Deviations, blocked/inconclusive items and defects
08 Security/privacy/usability/resilience evidence references
09 Downtime, restore, reconciliation and rollback evidence
10 Residual risk, release decision and expiry
11 Production monitors, runbooks and ownership
12 Change history, retention and access record

Report باید محدودیت و Unknown را کنار نتیجه نشان دهد. Evidence قابل ممیزی یعنی بتوان فهمید چه کسی، چه چیزی را، با کدام نسخه و روش، چه زمانی اجرا یا بررسی کرده است؛ نه اینکه خروجی حتماً تصمیم Go تولید کند.

نقش‌ها و تفکیک تصمیم

نقش	مسئولیت نمونه	نباید به‌تنهایی ادعا کند
QA/Test	طراحی/اجرای Evidence، محدودیت و Defect	اثربخشی بالینی یا انطباق کل سازمان
Developer/Architect	Design، implementation، review و observability	پذیرش مستقل Risk ایجادشده توسط خود
Clinical/domain owner	Workflow، content، oracle و consequence context	صحیح‌بودن فنی بدون Evidence
Human factors/UX	کاربر هدف، task، study و analysis	نمایندگی همه کاربران با expert opinion
Security/Privacy	threat/privacy assessment و control requirements	Patient safety کامل
Regulatory/Quality	Applicability، process و submission/audit scope	تضمین رفتار نرم‌افزار بدون V&V
Operations/SRE	deployment، monitoring، continuity و incident response	تغییر Clinical rule بدون owner
Authorized risk owner	تصمیم release و residual risk	نادیده‌گرفتن الزام یا safety gate بدون فرایند

RACI ثابت برای همه سازمان‌ها مناسب نیست. اصل مهم این است که Content approval، Evidence generation، independent review و Risk acceptance قابل تشخیص باشند و Emergency path نیز Audit و expiry داشته باشد.

آزمایش بازتولیدپذیر: Transport سبز، Context غلط

برای نشان‌دادن تفاوت انتقال و معنای Workflow، یک Fixture کاملاً ساختگی ساخته شد. هیچ بیمار، دارو، دوز، پزشک، مؤسسه یا داده واقعی در آن نیست. دو Patient مصنوعی P-۱۰۰ و P-۲۰۰ عمداً نام نمایشی یکسان «بیمار آزمایشی» دارند؛ دو Order با Itemهای خیالی SYN-A و SYN-B و Unitهای بی‌معنای UNIT-X/Y ایجاد می‌شوند. برای O-۱۰ نسخه ۲ وضعیت را Discontinued می‌کند، سپس duplicate و نسخه ۰ قدیمی دیر می‌رسند.

Fixture: fictional-health-it-orders-v1
Deliveries: 6

Naive consumer:
- key = displayName
- every delivery overwrites current state

Contract-aware consumer:
- entity key = patientId | encounterId | orderId
- same entity+version = duplicate/no-op
- lower version = stale/historical, never current

روش	پیام پذیرفته/تحویل	Current state	Duplicate	Stale	نتیجه
Transport gate	۶ از ۶	بررسی نمی‌کند	بررسی نمی‌کند	بررسی نمی‌کند	PASS
Naive: displayName + arrival wins	۶ از ۶	۱ وضعیت؛ P-۱۰۰/O-۱۰ v0 Active	پذیرفته	Current شده	هویت‌ها ادغام و State عقب رفته
Contract-aware	۶ از ۶	۲ وضعیت؛ P-۱۰۰ v2 Discontinued، P-۲۰۰ v1 Active	۲ کنار گذاشته	۱ تاریخی	Invariantهای Fixture حفظ شدند

{
  "transport": { "accepted": 6, "delivered": 6, "pass": true },
  "naive": {
    "currentStates": 1,
    "state": [{ "patientId": "P-100", "orderId": "O-10", "version": 0, "status": "active" }]
  },
  "contractAware": {
    "currentStates": 2,
    "duplicatesIgnored": 2,
    "staleIgnored": 1,
    "states": [
      { "patientId": "P-100", "orderId": "O-10", "version": 2, "status": "discontinued" },
      { "patientId": "P-200", "orderId": "O-20", "version": 1, "status": "active" }
    ]
  }
}

این خروجی فقط مکانیک شش Event دست‌نویس را ثابت می‌کند. نشان نمی‌دهد یک EHR، Interface، استاندارد، بیمارستان یا Workflow واقعی امن است؛ احتمال یا شدت Harm را اندازه نمی‌گیرد؛ قانون درست Patient matching یا State machine پزشکی ارائه نمی‌کند؛ و Benchmark، Coverage target یا Threshold عمومی نیست. Fixture عمداً برای آشکارکردن Failure طراحی شده و نتیجه آن قابل تعمیم آماری نیست.

درس محدود اما مهم این است: Delivery count باید با Identity invariant، Version rule، Idempotency، Current-state query و Reconciliation تکمیل شود. Contract واقعی باید توسط صاحبان دامنه و معماری محصول تعیین شود.

سناریوی بومی: کلینیک آزمایشی فارسی و قطعی ارتباط

یک Pilot کاملاً مصنوعی برای کلینیک فرضی در ایران در نظر بگیرید: ثبت بیمار ساختگی، ایجاد سفارش آزمایشی، ارسال به سرویس Lab Stub، بازگشت Result غیرپزشکی، نمایش فارسی و قطعی شبکه. محیط به هیچ سامانه ملی، بیمارستان، آزمایشگاه، پزشک، بیمار، پیامک، پرداخت یا Device واقعی وصل نیست و هیچ توصیه مقرراتی درباره ایران ارائه نمی‌کند.

ریسک	تزریق مصنوعی	Invariant	شاهد
Patient collision	دو نام یکسان با ID متفاوت	Context هر Order مستقل است	UI + API + audit correlation
Unicode	ی/ی، ک/ک، نیم‌فاصله، ارقام سه‌گانه	نمایش درست؛ Identity collision خاموش رخ ندهد	search/match negative cases
Time	UTC و Asia/Tehran؛ شمسی فقط نمایش	ترتیب canonical حفظ و timezone آشکار است	event timeline
Network cut	Timeout بعد از commit	retry Order دوم نسازد	idempotency + reconciliation
Late event	نسخه قدیمی بعد از توقف	Current state عقب نرود	state history/query
Downtime	Lab Stub unavailable	کاربر Completed کاذب نبیند	queue/alert/fallback rehearsal
RTL	جدول، Modal، print و mixed LTR IDs	Patient/Order و state قابل تمایزند	visual + user task review

Artifactها با checksum داخلی، dependency cache و Fixture seed ذخیره می‌شوند تا اجرای آفلاین ممکن باشد. تمام نام‌ها SYNTHETIC، Codeها خیالی و مقدارها فاقد معنای بالینی‌اند. اگر تیم روزی Sandbox بیرونی اضافه کند، قرارداد، مالک داده، دسترسی شبکه، عدم استفاده از اطلاعات واقعی و محدودیت محیط باید دوباره تصویب شوند.

برنامه ۳۰روزه برای شروع

هفته	خروجی	فعالیت	معیار اتمام
۱: Scope	Context Contract و Applicability Matrix	انتخاب یک Workflow، Actor، Intended Use، exclusion و owner	مرز و Claimها امضا و نسخه‌دارند
۲: Risk	Workflow map، Hazard scenarios و Traceability	walkthrough چندنقشی و تعیین Control/Oracle	هر Hazard مهم owner و Evidence plan دارد
۳: Evidence	Fixture مصنوعی و Test pack	identity، state، duplicate، stale، failure، usability و downtime	نتایج با Build/Config/Data قابل بازتولیدند
۴: Decision	Release memo و monitoring	تمرین restore/reconcile، review unknown و runbook	Residual risk، decision و expiry ثبت شده‌اند

• یک Workflow محدود و پرمعنا انتخاب کنید، نه کل بیمارستان.
• حداقل یک متخصص Workflow، یک QA، یک مهندس و یک مالک عملیات در walkthrough حاضر باشند.
• پنج تا ده Hazard Scenario را عمیق کنید، نه صد عنوان بدون Control.
• Fixture مصنوعی را با collision، duplicate، stale و outage بسازید.
• Evidence و limitation را قبل از اجرای Gate تعریف کنید.
• در پایان Pilot، defect count را هدف نگیرید؛ ببینید آیا تصمیم و Unknown روشن‌تر شده‌اند.

ضدالگوهای رایج در تست سامانه سلامت

ضدالگو	چرا خطرناک است؟	اصلاح
هر اپ سلامت = HIPAA/Medical Device	شمول و jurisdiction را حدس می‌زند	Applicability decision حقوقی/Regulatory
Testing guarantees safety	محدودیت Evidence و Residual risk را پنهان می‌کند	Claim محدود + limitation + owner decision
HTTP 200 = Integration pass	معنا، هویت و Workflow را نمی‌سنجد	Layered contract + reconciliation
نام بیمار = Identity	Collision و wrong-patient context می‌سازد	stable IDs و merge/unmerge scenarios
FHIR JSON = Interoperability	Profile، terminology و business rule جا می‌ماند	IG-pinned validation + E2E
DICOM image opens = compatible	Workflow، SOP و metadata را نمی‌سنجد	Statement comparison + equipment validation
Production copy with names masked	بازشناسایی و leakage ممکن است	Synthetic-first + formal data decision
QA invents clinical oracle	Expected result بی‌اعتبار است	versioned rule/content owner
Average latency only	tail، freshness و backlog پنهان می‌شود	journey/slice/tail/recovery metrics
Backup job green	قابلیت restore/reconcile معلوم نیست	clean restore exercise
Pass rate gate	Critical blocked test گم می‌شود	Hazard-based readiness
Monitoring infrastructure only	wrong/stale clinical state دیده نمی‌شود	Claim-level signals
Downtime = maintenance page	workflow انسانی و بازگشت جا می‌ماند	exercise + reconciliation
Usability by QA role-play	کاربر هدف نمایندگی نمی‌شود	appropriate user research/simulation
Blocked = skipped	Unknown به موفقیت ظاهری تبدیل می‌شود	Exposure و owner صریح

چک‌لیست نهایی تست نرم‌افزار سلامت

• Intended Use، user، setting، population، workflow و exclusion نسخه‌دارند.
• نوع محصول و Applicability توسط نقش‌های صلاحیت‌دار تعیین شده است.
• Claimها محدود و به Hazard/Requirement/Control وصل‌اند.
• Patient، encounter، order، specimen، result، device و practitioner هویت جدا دارند.
• Merge/Unmerge، collision، context switch و چند Tab آزموده شده‌اند.
• State machine، version، duplicate، late event و retry Contract دارند.
• Clinical content/Rule و Oracle مالک و نسخه مشخص دارند.
• FHIR/HL7/DICOM با نسخه/Profile/Statement و Workflow واقعی آزموده‌اند.
• Terminology، code system، unit، precision، timezone و provenance کنترل شده‌اند.
• Migration با semantic invariant و reconciliation فراتر از Count بررسی شده است.
• داده Synthetic-first است و هیچ PHI/PII در fixture/log/ticket نشت نمی‌کند.
• Security، Privacy، Usability و Accessibility برنامه و Owner جدا دارند.
• Performance با workload، tail، freshness، degradation و recovery سنجیده شده است.
• Downtime، restore، return-to-service و reconciliation تمرین شده‌اند.
• Code، Config، Rule، Terminology، Permission و Flag همگی Release identity دارند.
• Critical Hazardها Evidence تازه و محدودیت روشن دارند.
• Blocked، Inconclusive، Not-run و Stale به‌عنوان Unknown گزارش می‌شوند.
• Residual risk و Release decision مالک و expiry دارند.
• Production monitoring به Claim و Workflow، نه فقط زیرساخت، متصل است.
• Incident/Near miss به Action، effectiveness check و Regression fixture برمی‌گردد.

سؤالات متداول تست نرم‌افزار سلامت

آیا Pass شدن تست‌ها یعنی نرم‌افزار پزشکی ایمن است؟

خیر. Pass فقط رفتار مشاهده‌شده را در Scope، Build، Config، داده، روش و Oracle مشخص گزارش می‌کند. ایمنی به طراحی، Hazard control، محتوای بالینی، انسان، فرایند سازمانی، عملیات و شواهد متعدد وابسته است. محدودیت‌ها و Residual Risk باید به صاحب اختیار گزارش شوند.

آیا همه اپلیکیشن‌های سلامت باید HIPAA، FDA، HL7 و DICOM را رعایت کنند؟

نه. شمول به کارکرد، نقش سازمان، نوع داده، بازار، حوزه قضایی، Intended Use، طبقه‌بندی و Interfaceهای محصول بستگی دارد. حقوقی، Privacy، Regulatory و Quality باید منبع و نسخه لازم را تعیین کنند؛ QA سپس Requirement مصوب را به Test و Evidence تبدیل می‌کند.

آیا Valid شدن FHIR Resource، سازگاری کامل را ثابت می‌کند؟

خیر. Validator می‌تواند ساختار، Profile، invariant و بخشی از Terminology را بررسی کند، اما Business rule، authorization، Patient matching، workflow، رفتار طرف مقابل و استفاده انسانی نیازمند تست‌های دیگرند. نسخه FHIR و IG/Package نیز باید pin شوند.

برای محیط تست سلامت از داده واقعی استفاده کنیم؟

پیش‌فرض امن‌تر، داده مصنوعی نسخه‌دار و تکرارپذیر است. اگر نیاز واقعی به Extract وجود دارد، ضرورت، روش de-identification، ریسک بازشناسایی، دسترسی، محل، retention، audit و destruction باید با تصمیم رسمی Privacy/Legal/Security کنترل شود. حذف نام به‌تنهایی کافی نیست.

از کدام سناریو برای شروع تست HIS یا EHR استفاده کنیم؟

یک Workflow محدود با پیامد و handoff روشن انتخاب کنید؛ مثلاً ثبت بیمار مصنوعی تا سفارش و نتیجه غیرپزشکی در Sandbox. Context Contract، سه تا ده Hazard، شناسه‌های Patient/Encounter/Order، duplicate/stale event، قطعی، reconciliation و یک Release memo بسازید. کل سامانه را یک‌باره وارد Pilot نکنید.

جمع‌بندی: هدف، شواهد قابل‌ردگیری برای تصمیم بهتر است

تست نرم‌افزار سلامت از Context آغاز می‌شود، نه از ابزار. Intended Use و Clinical Workflow مرز را می‌سازند؛ Hazard و Claim تعیین می‌کنند چه چیزی باید کنترل شود؛ هویت، State، Terminology و Interoperability معنای داده را حفظ می‌کنند؛ Usability، Security، Privacy، Performance و Downtime شرایط استفاده را می‌سنجند؛ و Evidence Pack همراه با Unknown و Residual Risk، تصمیم Release را پاسخ‌گو می‌کند.

سبزشدن Transport مفید است، اما کافی نیست. پرسش نهایی این نیست که «چند تست Pass شد؟»؛ این است که «برای کدام Claim و Hazard، در کدام نسخه و Context، چه شاهدی داریم، چه چیزی هنوز نمی‌دانیم و چه کسی با دانستن آن تصمیم می‌گیرد؟»