Tasarım Geçmişi Dosyası (DHF)

Bu konu, şu konunun bir parçasıdır: SG Systems Global Düzenleme ve operasyon kılavuzu kütüphanesi.

Tasarım Geçmişi Dosyası (DHF): Denetime hazır tasarım kanıtları oluşturun—gereksinimler, risk, doğrulama ve geçerlilik, devir ve değişiklikler.

Ocak 2026'da güncellendi • tasarım geçmişi dosyası (dhf), tasarım kontrolleri, izlenebilirlik matrisi, risk yönetimi, doğrulama ve geçerlilik, tasarım transferi • Tıbbi cihazlar

Tasarım Geçmişi Dosyası (DHF), bir tıbbi cihazın tasarımının, gereksinimlerin tanımlanması, risklerin değerlendirilmesi, tasarım kararlarının gözden geçirilmesi ve doğrulama/geçerlilik işlemlerinin tamamlanması gibi disiplinli tasarım kontrolleri altında gerçekleştirildiğini kanıtlayan, kontrollü bir kayıt koleksiyonudur. Bu, "PDF'lerden oluşan bir klasör" değildir. Bir düzenleyici kurumun, denetçinin veya iç incelemecinin neyi inşa etmeyi amaçladığınızı, aslında neyi inşa ettiğinizi, bunu nasıl kanıtladığınızı ve değişiklikleri nasıl kontrol ettiğinizi anlamasını sağlayan kanıt zinciridir.

Bir DHF (Tasarım Temeli), 21 CFR Bölüm 820 kapsamındaki tasarım kontrollerinin ve ISO 13485 kapsamındaki tasarım ve geliştirme beklentilerinin merkezinde yer alır . AB'de aynı amaç, genellikle CE işaretlemesinin bir parçası olarak yetkili bir kuruluş tarafından incelenen AB MDR 2017/745 kapsamındaki teknik dokümantasyon aracılığıyla ifade edilir . Farklı dosyalama yapısı, aynı soru: Yayınlanan tasarım için kontrollü gereksinimleri, risk kontrollerini ve objektif kanıtları kanıtlayabilir misiniz?

Çoğu tasarım kanıt formu (DHF) basit bir nedenden dolayı başarısız olur: ekipler "tasarım kanıtını" bir çıktıdan ziyade bir yan ürün olarak görür. Tasarım çıktıları üretilir, test raporları birikir ve toplantılarda kararlar alınır; ancak bağlantı dokusu (izlenebilirlik, inceleme kayıtları, gerekçe ve değişiklik bağlantısı) eksiktir. İşte o zaman bir DHF karmaşaya dönüşür: sonradan kanıtları bir araya getirmek, kararların neden alındığını ve testlerin gerçekten tasarım amacını karşılayıp karşılamadığını yeniden oluşturmaya çalışmak.

"İzini süremezseniz, savunamazsınız."

1) DHF'nin gerçekte ne anlama geldiği

DHF, tasarımın kontrol altında olduğunun uçtan uca kanıtıdır. Bu kanıt tipik olarak şunları içerir:

• niyet: Kullanıcının kim olduğu, hangi sorunu çözdüğünüz ve "başarı"nın neye benzediği (genellikle şu şekilde ifade edilir): URS veya eşdeğer kullanıcı ihtiyaçları).
• Girişler: Tasarım gereksinimleri, standartlar, performans özellikleri ve kısıtlamalar.
• Çıkışlar: Çizimler, teknik özellikler, yazılım derlemeleri, etiketleme ve talimatlar.
• Yorumlar: Belgelenmiş tasarım incelemeleri ve eylem kapanışı.
• Risk kontrolleri: Tasarım ile bağlantılı risk analizi ve kontrol önlemleri (ISO 14971 hizalama).
• Doğrulama ve geçerlilik kanıtı: Protokoller ve sonuçlar, gerekliliklerin karşılandığını kanıtlamıştır (V&V).
• Transfer kanıtı: Yayınlanan tasarımın kontrollü üretim kayıtlarına devredildiğine dair kanıt (DMR).

Bir DHF (Tasarım Kılavuzu) "tek bir belge" değildir. Kontrollü bir kayıt sistemidir. Pratik hedef basittir: Yetkin bir gözden geçiren, tahmin yürütmeden, boşluklar olmadan ve bireysel hafızaya güvenmeden tasarım öyküsünü takip edebilir.

2) DHF disiplininin neden pazarlık konusu olmadığı

DHF kalitesini gerçek kılan dört itici güç vardır:

Acı gerçek şu: Zayıf bir DHF (Tasarım ve Güvenlik Dosyası) sadece denetim bulgusu riskini taşımakla kalmaz, aynı zamanda operasyonel gecikmelere de yol açar. Mühendisler eski kanıtlar kullanılamaz hale geldiği için testleri tekrar yaparlar. Kalite güvence departmanı risk dosyası güncel olmadığı için ürün lansmanlarını engeller. Düzenleyici kurum, onaylanmış bir kuruluşun sorularını yanıtlayamaz . Üretim "son seferde işe yarayanı" üretir ve üretilen cihaz, onaylanmış tasarımdan uzaklaşır. Küçük dokümantasyon zayıflıkları, düzenleyici gecikmelere, uzun soruşturmalara ve önlenebilir ürün riskine dönüşür.

DHF disiplini sizi "sessiz arıza"dan da korur. Bir cihaz üretimde istikrarlı görünürken, yavaş yavaş belgelenmemiş değişiklikler biriktirebilir: tedarikçi değişiklikleri, yazılım yamaları, etiketleme güncellemeleri, test yöntemi sapmaları ve gayri resmi teknik özellik değişiklikleri. Zamanla, gönderdiğiniz ürün, kanıtladığınız ürün olmayabilir. Değişiklik kontrolüne sıkıca bağlı güçlü bir DHF, bu sapmayı önlemenin yoludur.

3) DHF, DMR ve DHR karşılaştırması

Ekipler bunları birbirine karıştırıyor. Kafa karışıklığı, kanıtların kaybolmasına ve yanlış saklama uygulamalarına yol açıyor.

İncelemecilerin izlediği zinciri düşünün: DHF tasarımı kanıtlar; DMR onaylanmış yapıyı açıklar; DHR yapının onaylandığı gibi gerçekleştiğini kanıtlar. Bu kavramları birbirinden ayrı tutamazsanız, kanıtlarınız dağınık ve kırılgan olacaktır.

Pratik bir öz denetim yöntemi: Yüksek riskli bir gereksinimi seçin ve izleme zincirini baştan sona çalıştırın. Onaylanmış tasarım girdisini, bağlantılı risk kontrolünü, onu uygulayan tasarım çıktısını, doğrulama protokolünü, ham sonuçları, sapmayı (varsa) ve nihai kabul kararını elde edebilmelisiniz. Herhangi bir bağlantı yalnızca birinin hafızasında kalıyorsa, denetim sırasında kontrollü kanıt olarak kabul edilmez.

Pratikte, en savunulabilir yaklaşım, DHF'yi kontrollü bir "hikaye" ve DMR/DHR'yi kontrollü bir "uygulama" olarak ele almaktır. Eğer DHF'niz çoğunlukla üretim seyahat belgeleri ve denetim kayıtlarından oluşuyorsa, bir şey inşa ettiğinizi kanıtlıyorsunuz demektir; doğru şeyi kontrollü bir şekilde tasarladığınızı değil.

4) Kapsamı tanımlayın: DHF'ye nelerin dahil edilmesi gerekir?

Kapsam, DHF'lerin ya güçlendiği ya da kaotik hale geldiği yerdir. Dosya, kontrolü kanıtlamak için yeterli kanıt içermeli, ancak incelemeyi imkansız hale getirecek kadar fazla ilgisiz operasyonel gürültü içermemelidir.

Pratik bir DHF kapsam haritası tipik olarak şunları içerir:

• Kullanıcı ihtiyaçları / kullanım amacı: Cihazın ne için kullanıldığı, kimin kullandığı ve kullanım ortamı (genellikle şunlarla bağlantılıdır): IFU içeriği).
• Tasarım girdileri: Gereksinimler, standartlar, performans ihtiyaçları, güvenlik kısıtlamaları ve etiketleme gereksinimleri.
• Tasarım çıktıları: Çizimler, malzeme listeleri (BOM), teknik özellikler, yazılım gereksinimleri ve derlemeleri, etiketleme/grafikler ve kabul kriterleri.
• Tasarım incelemeleri: Gündemleri, katılımcıları, konuları, kararları ve eylem kapanışlarını gözden geçirin (aşağıda saklanır). Doküman Kontrolü).
• Risk yönetimi: Tehlike analizi, risk tahminleri, risk kontrolleri ve kalan riskin kabul edilebilirliği ile uyumlu hale getirilmiştir. ISO 14971.
• Doğrulama kanıtı: Tasarım girdilerinin karşılandığını kanıtlayan testler, incelemeler, analizler ve sonuçlar.
• Doğrulama kanıtı: Cihazın kullanıcı ihtiyaçlarını ve kullanım amacını karşıladığına dair kanıtlar (genellikle klinik, kullanılabilirlik ve uygun olduğu durumlarda simüle edilmiş kullanım testleri dahil).
• Tasarım aktarımına dair kanıtlar: Yayınlanan tasarımın aktarıldığına dair kanıt. DMR.
• Tasarım değişiklikleri: Değişiklik talepleri, gerekçeler, etki değerlendirmeleri ve güncellenmiş doğrulama ve geçerlilik sonuçları şunlarla ilişkilidir: kontrolü değiştir.

5) İzlenebilirlik: DHF'nin "omurgası"

İzlenebilirlik, bir DHF'nin (Derin Evrak Araştırması) bir yığın eser olmaktan çıkıp savunulabilir bir kanıt haline gelmesinin yoludur. En azından, şu soruları destekleyen çift yönlü izlenebilirliğe ihtiyacınız vardır:

• İleri izleme: Her kullanıcı ihtiyacı ve tasarım girdisi için, hangi tasarım çıktıları bunu hayata geçirir ve hangi doğrulama bunu kanıtlar?
• Geriye doğru izleme: Her bir tasarım çıktısı ve test, hangi gereksinimi veya risk kontrolünü destekliyor?
• Risk izleme: Belirlenen her bir tehlike için hangi risk kontrolü uygulandı ve bunun işe yaradığını kanıtlayan deliller nelerdir?

İzlenebilirlik genellikle bir izlenebilirlik matrisi aracılığıyla işlevsel hale getirilir. Bu matrisin başarısı, yönetimine bağlıdır: sürümlendirilir, gözden geçirilir ve her anlamlı değişiklikte güncellenir. Matrisi, bir mühendisin özel elektronik tablosu olarak değil, revizyon kontrolü altında olan kontrollü bir unsur olarak ele alın.

İzlenebilirlik, eksiklikleri ortaya çıkarmanın en hızlı yoludur. Her gereksinimi objektif kanıtlarla eşleştiremiyorsanız, ya gereksinim tanımlanmamıştır, ya test planı zayıftır ya da kanıt eksiktir. Her üçü de sorundur ve DHF, bu sorunların görünür ve çözülebilir olması gereken yerdir.

6) Yönetişim: belge kontrolü, incelemeler ve kanıtlar

DHF (Derinleşik Henle-House) bir kalite kaydıdır. Bu da, bir kalite kaydı gibi yönetilmesi gerektiği anlamına gelir. Bürokrasinin kendi başına bir amaç olması gerekmez, ancak denetlenebilir ve tekrarlanabilir bir disipline ihtiyaç vardır.

Temel yönetim unsurları:

• Doküman Kontrolü: Kontrollü şablonlar, onaylar, geçerlilik tarihleri ​​ve mevcut sürümler.
• Gözden geçirme: Gereksinimler, teknik özellikler, çizimler, yazılım temel sürümleri ve izlenebilirlik matrisleri için sürümleme.
• Kontrolü değiştir: Tasarım değişiklikleri meydana geldiğinde, net etki değerlendirmesi ve kanıt güncellemeleri yapılmalıdır.
• Tasarım inceleme disiplini: Planlı değerlendirmeler, objektif girdiler ve belgelenmiş sonuçlarla yapılır; eylemin tamamlanması, yan bir görüşme değil, kayıtların bir parçasıdır.
• Denetlenebilirlik: Kanıtlar, yıllar sonra bile erişilebilir ve yorumlanabilir olmalı; güvenilirlik için gerektiğinde ham veriler de dahil edilmelidir.
• Kalite sisteminin uyumlaştırılması: DHF yönetimi sizinle uyumlu olmalıdır. KYS ve, geçerli olduğu durumlarda, QMSR.

Elektronik kayıtlar için yönetim, 21 CFR Bölüm 11 ve Ek 11 beklentileriyle uyumlu olmalıdır : kimlik, erişim kontrolü, denetim izleri, kayıt saklama ve alma. En basit işletme kuralı: bir kayıt güvenlik, performans veya uyumluluğu etkileyebiliyorsa, kontrollü kalite kaydı gibi korunmalıdır, çünkü zaten öyledir.

7) Risk yönetimi entegrasyonu (ISO 14971)

Risk yönetimini göz ardı eden bir DHF (Tasarım Kılavuzu) eksiktir. Modern cihaz incelemelerinde risk ayrı bir dosya değildir; tasarım mantığının bir parçasıdır.

DHF içeriği en azından şunları göstermelidir:

• Tehlike analizi ve risk değerlendirme yaklaşımı (uyumlu olarak) ISO 14971 Tıbbi Cihaz Risk Yönetimi)
• Seçilen, uygulanan ve doğrulanan risk kontrolleri
• Tehlikeden → kontrol önlemine → tasarım çıktısına → doğrulama kanıtına kadar izlenebilirlik
• kalıntı risk değerlendirmesi ve kabul edilebilirlik gerekçesi

Risk entegrasyonundaki başarısızlıkların çoğu izlenebilirlik başarısızlığıdır. Ekipler, somut bir tasarım çıktısına eşlenmeyen risk kontrolleri yazarlar veya hangi risk kontrolünü doğruladıklarını açıkça belirtmeyen testler yaparlar. Kayıt, bir kontrolün var olduğunu ve çalıştığını gösteremezse, inceleyiciler bunun mevcut olmadığını varsayacaktır.

8) Doğrulama ve geçerlilik: Denetçilerin aradığı özellikler

Doğrulama ve geçerlilik, DHF'lerin savunulmasının kolaylaştığı veya zorlaştığı aşamadır. Gözden geçirenler net bir ayrım ve net bir bağlantı ararlar:

Sık karşılaşılan bir denetim sorunu, "gereksinim bağlantısı olmayan test kanıtları"dır. Raporlar mevcuttur, ancak bunlar tasarım girdilerine veya risk kontrollerine açıkça bağlı değildir. Bir diğer sorun ise "nesnel kabul kriterleri olmayan gereksinimler"dir. Pazarlama iddiaları gibi görünen gereksinimler doğrulanamaz. Bu nedenle gereksinim kalitesi sadece bir mühendislik sorunu değil, aynı zamanda bir DHF (Tasarım, Tasarım ve Fonksiyonel Tasarım) sorunudur.

Cihazınızda kullanılabilirlik veya kullanıcı arayüzü riski varsa, DHF doğrulama kanıtlarını İnsan Faktörleri Mühendisliği (HFE) çalışmalarıyla ilişkilendirin. DHF'de kullanılabilirlik riskini göz ardı ederseniz, daha sonra saha hataları ve şikayet eğilimleri olarak ortaya çıkacak bir kör nokta yaratırsınız.

9) Tasarımın aktarılması ve üretime devredilmesi

Tasarım transferi, DHF kanıtlarının kontrollü üretim gerçekliğiyle bağlantı kurması gereken noktadır. Üretim, doğrulanmış ve geçerliliği onaylanmış tasarımı üretemezse, "Tasarımı tamamladık" ifadesi anlamsızdır.

Savunulabilir bir tasarım aktarım öyküsü tipik olarak şunları içerir:

• Son yayınlanan tasarım çıktıları ve özellikleri
• Üretim ve denetim talimatları, aşağıdakilerin altına yerleştirilmiştir. DMR
• Süreç doğrulama kararları ve gerekçeleri (uygulanabilir olduğu durumlarda)
• tedarikçi gereksinimleri ve kontrolleri ile uyumlu tedarikçi kalite yönetimi
• üretim kanıtı beklentilerine bağlantı DHR or eDHR

Aktarım hataları genellikle uygunsuzluklar ve şikayetler şeklinde ortaya çıkar: yanlış kabul testleri, belirsiz iş talimatları, eksik denetim adımları ve "kurumsal bilgiye" dayalı üretimler. Bunlar sadece üretimle ilgili sorunlar değildir. Bunlar DHF (Tasarım Geliştirme Merkezi) sorunlarıdır çünkü DHF, yayınlanan tasarımın amaçlandığı gibi üretilebilir olduğuna dair kanıtların sahibidir.

10) Değişiklik kontrolü ve tasarım evrimi

Cihazlar sürekli gelişiyor. DHF'niz de onlarla birlikte gelişmeli. Temel kural basit: bir değişiklik gereksinimleri, riski, etiketlemeyi, performansı veya güvenliği etkiliyorsa, kontrol edilmeli ve izlenebilir olmalıdır.

DHF bağlamında minimum değişiklik kontrolü beklentileri:

• Etki değerlendirmesi: Hangi gereksinimler, risk kontrolleri veya doğrulama iddiaları değişebilir?
• Kanıt güncellemesi: Hangi doğrulama veya geçerlilik testinin yeniden çalıştırılması gerekiyor?
• İzleme güncellemesi: İzlenebilirlik matrislerini ve risk bağlantılarını güncelleyin.
• Onay kaydı: belgelenmiş onaylar kapsamında kontrolü değiştir.

Değişiklik kontrolü, DHF'lerin (Tasarım El Kitabı) sıklıkla güncelliğini yitirdiği noktadır. Ekip tasarım çıktısını günceller ve yayınlar, ancak izleme matrisi güncellenmez, risk dosyası tekrar gözden geçirilmez ve test planı geçen yılın varsayımlarına bağlı kalır. Bu durum, "tamamlanmış gibi görünen" ancak mevcut tasarım için gerçek anlamda tamamlanmamış bir DHF oluşturur.

11) Yazılım ve SaMD gerçekleri

Yazılım ağırlıklı cihazlar ve IEC 62304 standartlarına tabi yazılım geliştirme süreçlerinde, DHF beklentileri ortadan kalkmaz, aksine artar. Gözden geçirenler, kontrollü temel değerler, yazılım gereksinimlerinden testlere kadar izlenebilirlik ve disiplinli konfigürasyon yönetimi görmek isterler.

Yazılım odaklı ürünler için pratik bir DHF yaklaşımı şunları içerir:

• yazılım gereksinimleri ve mimarisi altında revizyon kontrolü
• Gereksinimlerden test senaryolarına ve sonuçlara kadar izlenebilirlik.
• Siber güvenlikle ilgili gereksinimler ve geçerli olduğu durumlarda doğrulama kanıtları.
• Sürüm notları tasarım değişiklikleri ve risk etkileriyle bağlantılıdır.
• Yayınlanan yazılım temel sürümünün, doğrulanmış ve geçerliliği onaylanmış olanla eşleştiğine dair kanıtlar

Yazılım sürüm süreciniz, etki değerlendirmesi ve izleme güncellemeleri yapılmadan "hızlı yamalar"a izin veriyorsa, DHF'niz hızla güvenilmez hale gelecektir. Yazılım için DHF, sürüm öyküsünü açıkça ortaya koymalıdır: ne değişti, neden, hangi riskler göz önünde bulunduruldu ve sürümü destekleyen kanıtlar nelerdir.

12) Geri bildirim döngüleri: şikayetler ve piyasa sonrası sinyaller

Bir DHF (Denizcilik Temelli Ürün) sonsuza dek dondurulmuş değildir. Pazarlama sonrası kanıtlar genellikle tasarım değişikliklerinin tetikleyicisidir. Saha performansınız pazarlama sonrası gözetim ve müşteri şikayetlerinin ele alınması yoluyla izleniyorsa , DHF yönetimi hızlı izleme tabanlı soruşturmayı desteklemelidir:

• Hangi gereklilik veya risk kontrolü söz konusudur?
• Bu tasarım çıktısı neyi hayata geçiriyor?
• Başlangıçta bunu destekleyen kanıtlar nelerdi?
• Hangi değişikliklere ihtiyaç duyuluyor ve hangi doğrulama ve geçerlilik testlerinin tekrarlanması gerekiyor?

İşte DHF kalitesinin karşılığını verdiği nokta burası. Bir şikayet geldiğinde, sorunun tasarım hatası mı, üretim hatası mı, etiketleme problemi mi yoksa kullanım hatası mı olduğunu hızlı bir şekilde belirleyebilmelisiniz. İzlenebilirlik olmadan, soruşturmalar görüşe ve gecikmeye dönüşür.

13) Saklanması gerekenler: DHF kanıt paketi

Bir DHF (Veri Kaçırma İddiası) ancak talep üzerine kanıt sunabiliyorsanız savunulabilir. Saklama süresi, kayıt saklama stratejinizle uyumlu olmalı ve elektronik kayıtların bütünlüğü denetlenmelidir.

Önerilen DHF kanıt paketi içeriği:

• DHF indeksi veya yapı haritası: DHF'nin nasıl organize edildiği ve önemli kayıtların nerede saklandığı.
• Kullanıcı ihtiyaçları ve tasarım girdileri: Kontrollü sürümler ve onay kayıtları.
• Tasarım çıktıları: Yayınlanmış çizimler/teknik özellikler/yazılım temel sürümleri ve bunların revizyonları.
• İzlenebilirlik matrisi: Çift yönlü izleme, sürümlü, gözden geçirilmiş.
• Risk yönetimi dosya bağlantısı: ISO 14971 standartları ve risk kontrol izleme sistemi.
• Doğrulama ve geçerlilik kanıtı: Protokoller, sonuçlar ve sapmalar.
• Tasarım inceleme kayıtları: Gündemler, katılımcılar, tutanaklar, alınan kararlar ve kapanış.
• Tasarım aktarımına dair kanıtlar: Paket serbest bırakma ve DMR devir teslim kanıtı.
• Değişiklik kayıtları: Değişiklik talepleri, etki değerlendirmeleri, onaylar ve yeniden test kanıtları.

Ayrıca, soruşturmayı destekleyecek şekilde DHF erişim ve değişiklik geçmişini de saklayın. İşte burada denetim izi beklentileri ve veri bütünlüğü önem kazanır. Kimin neyi ne zaman değiştirdiğini kanıtlayamazsanız, kaydın güvenilirliğini zayıflatırsınız.

14) Performans göstergeleri ve çalışma temposu

DHF (Derinleşik Hemodiyaliz Fonksiyonu) yılda bir kez yapılan bir uyumluluk ritüeli olmamalıdır. Ölçülebilir sonuçları olan bir işletme kontrolü olmalıdır.

İşlem sıklığı, risk ve değişim oranını yansıtmalıdır. Karmaşık cihazlar, sık yazılım güncellemeleri, birden fazla tedarikçi ve yüksek şikayet riski, istikrarlı ve düşük değişim oranına sahip ürünlere göre daha sık DHF sağlık kontrolleri gerektirir. Hızlı hareket ediyorsanız, DHF yönetiminiz de hızlı hareket etmelidir; aksi takdirde hayal ürünü olur.

15) “Denetim için hazır” DHF blok testi

Hızlı bir onay/red kontrolü istiyorsanız, DHF blok testini kullanın. Amaç, belge şablonlarınıza hayran kalmak değil, kayıt zincirinin sağlam olduğunu kanıtlamaktır.

Bu blok testini hızlı bir şekilde tamamlayamazsanız, DHF'niz hala "çok sayıda belge" içerebilir, ancak bir kontrol işlevi görmüyordur. Başarısızlığı bir kalite istisnası olarak değerlendirin ve düzeltin.

16) Yaygın arıza modelleri

• Kanıtlar mevcut ancak bunlar birbirine bağlanmamış. Test raporları mevcut, ancak gereksinimler ve risk kontrolleri bu raporlara dayandırılamıyor.
• Şartların doğruluğu teyit edilemez. Girdi metinleri, kabul kriterleri içermeyen pazarlama dili gibi görünüyor.
• Risk ayrı ve güncelliğini yitirmiş bir kavramdır. Tasarım değişiklikleri meydana geldiğinde ISO 14971 dosyası güncellenmez.
• Tasarım değerlendirmeleri gayriresmi niteliktedir. Kararlar alınır, ancak inceleme kayıtları gerekçeyi veya sonuca ulaşıldığını göstermez.
• Değişiklik kontrolü, hikayeyi değil, çıktıları günceller. Teknik özellikler değişir, ancak izlenebilirlik ve kanıt paketleri değişmez.
• Aktarım zayıf. Üretim, geleneksel bilgi birikimiyle şekillenir; DMR, onaylanmış tasarımı yansıtmaz.
• Elektronik kayıtların bütünlüğü göz ardı ediliyor. Net bir denetim izi, erişim yönetimi veya veri alma disiplini yok.
• DHF en sonda derlenmiştir. "Teslim etmeden önce bir araya getireceğiz" yaklaşımı, eksikliklerin kalıcı hale gelmesine yol açar.

17) Sektörler arası notlar: IVD, implantlar ve kombinasyon ürünleri

DHF'nin temel prensipleri evrenseldir, ancak vurgu cihaz türüne göre değişir:

• IVD cihazları: Tasarım girdilerini analitik performans kanıtlarıyla ve etiketleme/iddialarla ilişkilendirin; düzenleyici raporlama beklentilerine hazır olun, örneğin: 21 CFR Bölüm 803.
• İmplantlar: Malzemeler, biyouyumluluk gerekçesi ve uzun vadeli risk kontrolleri izlenebilir olmalı ve objektif kanıtlarla desteklenmelidir.
• Kombinasyon ürünler: Tasarım kanıtları, cihaz kontrolleri ile ilgili ilaç/biyolojik ürün beklentileri arasında bir köprü kurmalıdır (örneğin, kontrollerin etkilenmesi gibi). 21 CFR Bölüm 4).
• UDI / etiketleme kontrollü ürünler: Etiketleme gerekliliklerinden kontrollü çıktılara ve üretim kayıtlarına kadar izlenebilirliği sağlamak, örneğin: 21 CFR Bölüm 830.
• Saha düzeltme hazırlığı: DHF değişim disiplini, gerektiğinde hızlı ve savunulabilir eylemleri destekler (bkz. 21 CFR Bölüm 806 bağlam).

Ortak ders şu: DHF, piyasaya sürülen tasarımı savunulabilir kılmalı ve gerçek dünya evrimi zorunlu kıldığında değişikliği savunulabilir hale getirmelidir.

18) Genişletilmiş SSS

S1. Tasarım Geçmişi Dosyası (DHF) nedir?
DHF, tıbbi bir cihazın, gereksinimler, risk yönetimi, tasarım incelemeleri ve doğrulama/geçerlilik kanıtları da dahil olmak üzere, disiplinli tasarım kontrolleri altında tasarlandığını kanıtlayan, kontrollü bir kayıt koleksiyonudur.

S2. DHF ile DMR aynı mıdır?
Hayır. Bir DHF, tasarımın kontrollü olduğunu kanıtlar; DMR Yayınlanan tasarımın nasıl üretileceğini tanımlar.

S3. Denetimlerde DHF'nin en büyük zayıf noktası nedir?
İzlenebilirlik eksikliği: Gereksinimler ve risk kontrolleri, nesnel doğrulama/geçerlilik kanıtlarıyla açıkça ilişkilendirilmemiştir.

S4. ISO 14971'in DHF ile ilişkisi nedir?
DHF, risk kontrollerinin şu yönlerden etkili olduğunu göstermelidir: ISO 14971 Tasarım çıktılarında uygulanır ve objektif kanıtlarla doğrulanır.

S5. Bir DHF ne zaman "monte edilmelidir"?
Sürekli olarak. Eğer DHF'yi en sonda monte ederseniz, geliştirme sırasında kontrol mekanizması olarak çalışmadığını kabul etmiş olursunuz.

İlgili Okuma
• Tasarım Kontrolleri: Tıbbi Cihaz Tasarımı | 21 CFR Bölüm 820 | ISO 13485 | Doğrulama ve Onaylama (V&V)
• Risk + Kullanılabilirlik: ISO 14971 | İnsan Faktörleri Mühendisliği (HFE) | Pazarlama Sonrası Gözetim | Şikayet Yönetimi
• Kayıt Zinciri: DMR | DHR | eDHR | Kullanım Talimatları (IFU)
• Yönetim: Döküman kontrolu | Gözden geçirme | Kontrolü değiştir | CAPA | Risk matrisi | İç Denetim
• Elektronik Kayıtlar Bağlamı: 21 CFR Bölüm 11 | Ek 11 | Denetim İzi (GxP) | Veri bütünlüğü | Kayıt tutma
• AB Bağlamı: AB MDR 2017/745 | CE İşareti | Onaylanmış kuruluş