Über uns   |Kontakt|  Suche|  Blog  

Medizinische Software: Wissen, Beratung, Studium

Blog zur Healthcare-IT, Medizintechnik, Karriere und Leben

Medizinische Software schnell und 62304-konform entwickeln

Sonntag 15. Januar 2012 von Christian Johner

Holen Sie sich das kostenlose Infopaket (E-Book, Tutorial, FAQ), das Ihnen hilft, Ihr Medizinsoftware-Audit sicher zu bestehen.

 

Infopaket kostenlos herunterladen

VN:F [1.9.22_1171]
Rating: 4.6/5 (11 votes cast)

Kategorie: IEC 62304 & Co.
Tags: , , ,
Keine Kommentare »

Gebrauchstauglichkeitsakte: Eine gemeinsame für FDA und EU?

Mittwoch 23. April 2014 von Christian Johner

Was eine Gebrauchstauglichkeitsakte in Europa umfassen muss, beschreibt die IEC 62366 relativ klar. Und wie sieht es in den USA aus? Hier gibt es eine größere Menge an relevanten Regularien wie z.B.:

  1. Gesetzlicher Rahmen: z.B. 21 CFR part 820
  2. Guidance Document: Applying Human Factors and Usability Engineering to Optimize Medical Device Design
  3. Guidance Document: Total Product Life Cycle: Infusion Pump – Premarket Notification [510(k)] Submissions
  4. Guidance Document: FDA Guidance, Medical Device Use Safety: Incorporating Human Factors Engineering into Risk Management
  5. Recognized Standard: AAMI/ANSI HE75:2009, Human Factors Engineering – Design of Medical Devices
  6. Recognized Standards: IEC 62366, IEC 60601-1-8

Am genausten beschreibt das 2. Dokument (Applying Human Factors and Usability Engineering to Optimize Medical Device Design), wie sich die FDA eine Gebrauchstauglichkeitsakte vorstellt. Zum Glück lassen sich die geforderten Inhalte auch in euer IEC 62366 konformen Akte wiederfinden, wie die folgende Tabelle zeigt:

Contents Entsprechendes Kapitel in der IEC 62366
1. Intended device users, uses, use environments, and training

  • Intended user population(s) and critical differences in capabilities between multiple user populations
  • Intended uses and operational contexts of use
  • Use environments and key considerations
  • Training intended for users and provided to test participants
5.2
2. Device user interface

  • Graphical depiction (drawing or photograph) of device user interface
  • Verbal description of device user interface
5.5 und 5.8
3. Summary of known use problems

  • Known problems with previous models
  • Known problems with similar devices
  • Design modifications implemented in response to user difficulties
5.3.2
4. User task selection, characterization and prioritization

  • Risk analysis methods
  • Use-related hazardous situation and risk summary
  • Critical tasks identified and included in HFE/UE validation tests
5,5
5. Summary of formative evaluations

  • Evaluation methods
  • Key results and design modifications implemented
  • Key findings that informed the HFE/UE validation testing protocol
Teilweise in 5.8
6. Validation testing

  • Rationale for test type selected (i.e., simulated use or clinical evaluation)
  • Number and type of test participants and rationale for how they represent the intended user populations
  • Test goals, critical tasks and use scenarios studied
  • Technique for capturing unanticipated use errors
  • Definition of performance failures
  • Test results: Number of device uses, success and failure occurrences
  • Subjective assessment by test participants of any critical task failures and difficulties
  • Description and analysis of all task failures, implications for additional risk mitigation
5.6 und 5.9
7. Conclusion

Man kommt also mit einer Akte aus. Dass sich die Forderungen z.B. mit Bezug an die Methodik unterscheiden, ist eine andere Sache.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kategorie: IEC 62304 & Co.
Tags: , , , , ,
Keine Kommentare »

Zyklomatische Komplexität

Dienstag 22. April 2014 von Christian Johner

Die IEC 62304 verlangt in Kapitel 5.5.3 Akzeptanzkriterien für Software-Einheiten festzulegen und deren Einhaltung zu prüfen. Eine Möglichkeit, solche Akzeptanzkriterien zu bestimmen, sind Software-Metriken. Eine meiner Lieblingsmetriken ist die zyklomatische Komplexität auch McCabe Maß genannt. Diese Metrik gibt an, wie viele linear unabhängige Pfade es durch einen Programmgraf gibt. Einen Pfad definiert man dann als linear unabhängig, wenn er mindestens eine neue Kante enthält.

In diesem Beispiel gibt es vier linear unabhängige Pfade

Zyklomatische-Komplexität

  1. 2,7
  2. 1,4,6,9,10
  3. 1,4,6,9,8,9,10
  4. 1,3,5,9,10

Dabei geben die Zahlen die Kanten an, die jeweils durchlaufen werden. Den ganzen Beitrag lesen »

VN:F [1.9.22_1171]
Rating: 4.0/5 (1 vote cast)

Kategorie: IEC 62304 & Co.
Tags: , , , , , ,
1 Kommentar »

Gesetzliche Anforderungen an Medizinprodukte: Formulierungsschablone

Freitag 18. April 2014 von Christian Johner

Gesetzliche und normative Anforderungen an die Dokumentation gesetzlicher Anforderungen

Sowohl die ISO 13485 als auch die „Quality System Regulations“ der FDA (21 CFR part 820) verlangen, dass Hersteller von Medizinprodukten die gesetzlichen Anforderungen als Teil der Stakeholder-Anforderungen erfassen und dokumentieren. Selbst die IEC 62304 fordert dies in Kapitel 5.2.2 f).

Doch wie formuliert man gesetzliche Anforderungen korrekt und überprüfbar?

Dokumentation der gesetzlichen Anforderungen an Medizinprodukte

Verweisen Sie nicht global auf gesetzliche Anforderungen der Art „Die Datenschutzbestimmungen sind zu beachten“ oder noch unspezifischer „die gesetzlichen Bestimmungen müssen eingehalten werden“. Das ist ziemlich wertlos. Den ganzen Beitrag lesen »

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kategorie: IEC 62304 & Co.
Tags: , , , , ,
Keine Kommentare »

ISO TR 24971: Sicherheitsbezogene Informationen und Informationen über verbleibende Risiken

Donnerstag 17. April 2014 von Christian Johner

Der „Technical Report“ ISO TR 24971 merkt an, dass Hersteller von Medizinprodukten regelmäßig Schwierigkeiten hätten, sicherheitsbezogene Informationen und Informationen über verbleibende Risiken zu unterscheiden. Die Erklärung, die die ISO 24971 hierzu gibt, ist ebenso kurz wie einleuchtend:

Sicherheitsbezogene Informationen…

haben das Ziel, durch Hinweise an die Anwender, die Risiken durch das Medizinprodukt zu minieren. Das könnten Hinweise sein wie:

  • Entfernen Sie nicht diese Abdeckung, es besteht die Gefahr eines Stromschlags
  • Vorsicht: Die Medikamentendosis, die Sie verschreiben wollen, kann für diesen Patienten, der unter Herzinsuffizienz leidet, tödlich sein. Sind Sie sicher, dass Sie das tun wollen?

Die ISO 24971 weist nochmals darauf hin, dass solche Hinweise und Informationen die schwächste Maßnahme zur Risikominimierung sind und dass ein inhärent sicheres Design und Schutzmaßnahmen zu bevorzugen seien.

Informationen über verbleibende Risiken…

haben nicht das unmittelbare Ziel, die Handlung der Anwender zu ändern, sondern nur nochmals deren Bewusstsein für die sich ergebenden Risiken zu schärfen. Auch hier nennt die ISO 24971 Beispiele:

  • Linearbeschleuniger können zur Behandlung von Tumoren genutzt werden. Zu den verbleibenden Risiken einer Strahlentherapie zählen Hautverbrennungen und Haarverlust. Ein schönes Beispiel, wenn gleich es die wirklichen Risiken wie Sekundärtumore nicht nennt. Habe fünf Jahre in der Radioonkologie gearbeitet…
  • Patienten in einem Kernspingerät erfahren manchmal Platzangst und erschrecken durch die lauten Geräusche.

Wenn man sich fragt, welches Ziel man mit einer Information verfolgt, kann man sicherheitsbezogene Informationen und Informationen über verbleibende Risiken, beides Begriffe der ISO 14971, besser unterscheiden.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kategorie: Allgemein
Tags: , , , , ,
Keine Kommentare »

ISO TR 24971 zur Anwendung der ISO 14971

Mittwoch 16. April 2014 von Christian Johner

Kennen Sie schon die ISO TR 24971? Diese Norm wurde bereits im Juli 2013 veröffentlicht. Zum Glück handelt es sich dabei nicht um eine weitere harmonisierte Norm, deren Anforderungen wir erfüllen müssen, sondern um einen „Technical Report“, der Hilfestellungen zu ausgewählten Aspekten des Risikomanagements gibt, also wie man die ISO 14971 anwenden soll.

ISO-TR-24971-2013

Zu diesen in der ISO 24971 genannten Aspekten zählen: Den ganzen Beitrag lesen »

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kategorie: IEC 62304 & Co.
Tags: , ,
Keine Kommentare »

Abgrenzung ISO 9001 und ISO 13485

Dienstag 15. April 2014 von Christian Johner

Einige unserer Kunden, die wir dabei unterstützen dürfen, ein ISO 13485 konformes QM-System zu etablieren, sind bereits ISO 9001 zertifiziert. Ob es noch viel Arbeit sei, das bestehende QM-System auf ISO 13485 zu erweitern, ist meist eine der ersten Fragen, die man uns stellt.

ISO9001-ISO13485-Unterschiede

Die ISO 9001 und ISO 13485 sind „Geschwisternormen“ und zu 90% Buchstaben identisch. Einige Unterschiede gilt es dann aber zu beachten, die manchen Firmen doch noch etwas Arbeit bereiten: Die ISO 13485 verlangt im Gegensatz zur ISO 9001 Den ganzen Beitrag lesen »

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kategorie: IEC 62304 & Co.
Tags: , , , ,
Keine Kommentare »

Systemanforderungen: Welche “Unwörter” Sie vermeiden sollten

Montag 14. April 2014 von Christian Johner

In vielen Review-Checklisten zu Systemanforderungen bzw. Softwareanforderungen finden sich die Fragen-Klassiker wie:

  • Sind die Anforderungen widerspruchsfrei?
  • Sind die Anforderungen vollständig?
  • Sind die Anforderungen korrekt?
  • Usw.

Meiner Meinung nach sind solche Checklisten völlig nutzlos. Wie soll den der Reviewer herausbekommen, ob die Anforderungen widerspruchsfrei, vollständig und korrekt sind? Eine Checkliste ist nur dann geeignet, wenn man die Punkte eindeutig und reproduzierbar mit ja oder nein beantworten kann. Daher sind Fragen viel geeigneter wie:

  • Sind die Anforderungen alle nummeriert?
  • Sind die Anforderungen alle im Aktiv formuliert? Ggf. gemäß einer Formulierungsschablone.
  • Enthalten die Anforderungen keine „Week Words“?

Apropos Week Words: „Weichmacher“-Wörter sind starke Hinweise auf unpräzise Anforderungsdokumente. Dazu zählen Wörter wie

ausreichend, beinahe, circa, eben, eher, einfach, fast, gar, genug, gering, gut, häufig, irgend*, kaum, klein, leicht, manchmal, mehr, meist, nahezu, öfters, sehr, schnell, schon, schön, sonstige, übrige, verschieden, viel, zahlreich, zunächst, usw.

Diese Wörter lassen sich übringens mit einem Werkzeug schneller und zuverlässiger finden als mit einem Review.

Demnächst zeige ich Ihnen in kostenlosen(!) Videotrainings, wie Sie System- bzw. Softwareanforderungen schnell, präzise, stabil und vollständig dokumentieren können. Wenn Sie über diese informiert werden wollen, tragen Sie sich bitte in meinen IEC 62304-Newsletter ein, den Sie bekommen, wenn Sie sich das kostenlose Infopaket herunterladen.

Danke für die Anregung und “Worte” an Dr. Dieter Lederer, Vector Consulting Service

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kategorie: IEC 62304 & Co.
Tags: , ,
1 Kommentar »

IEEE 830: Software-Anforderungen systematisch dokumentieren?

Donnerstag 10. April 2014 von Christian Johner

Die IEEE 830 ist eine Norm, die beschreibt, wie man Software Anforderungen bzw. Software Spezifikationen beschreiben sollte. Die IEEE 830 schreibt dazu mindestens drei Kapitel vor:

  1. Einleitung mit Dokumenten Meta-Informationen (Zweck, Verweise, Aufbau) und mit einer Übersicht über die Software
  2. Allgemeine Beschreibung der Software: Hier sollte man die Abgrenzung zu/von anderen Systemen ebenso beschreiben wie die wichtigsten Produktfunktionen und Einschränkungen des Lösungsraums. Auch sieht die IEEE 830 eine Charakterisierung der Nutzer als Teil dieses Kapitels vor.
  3. Die spezifischen Anforderungen umfassen laut IEEE 830 funktionale und nicht-funktionale Anforderungen, Anforderungen an die Performanz, Qualitätsanforderungen, externe Schnittstellen und sonstige Anforderungen.

Eine detailliertere Kapitelübersicht der IEEE 830 bietet Wikipedia.

IEEE_Logo

Vorsicht mit der IEEE 830 bei Medizinprodukten

Ich möchte Sie warnen, für medizinische Software blind den Empfehlungen dieser Norm zu folgen, aus mehreren Gründen: Den ganzen Beitrag lesen »

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kategorie: IEC 62304 & Co.
Tags: , , , , ,
Keine Kommentare »

Wikipedia: Zitierfähig in wissenschaftlichen Arbeiten?

Mittwoch 9. April 2014 von Christian Johner

Darf man Wikipedia in einer wissenschaftlichen Abschlussarbeit wie einer Bachelorarbeit oder einer Masterarbeit zitieren oder darf man es eher nicht?

Wenn Experten um Antworten auf diese Frage ringen, diskutieren Sie meist die Güte und Verlässlichkeit der Wikipedia Artikel. Sie vergleichen diese mit konventionellen Lexika, beklagen die Manipulation der Artikel durch Lobbyisten, loben andererseits die Aktualität und kommen schlussendlich zu keinem Konsens.

Ziel des wissenschaftlichen Arbeitens

Lassen Sie mich einen vielleicht nützlicheren Gedanken ergänzen: Den ganzen Beitrag lesen »

VN:F [1.9.22_1171]
Rating: 5.0/5 (4 votes cast)

Kategorie: Lernen & Karriere
Tags: ,
1 Kommentar »

User Centered Design: Weshalb Sie damit vorsichtig sein müssen

Dienstag 8. April 2014 von Christian Johner

Jeder wird zustimmen, dass es gut ist, die künftigen Anwender von Anfang an, in die Entwicklung mit einzubeziehen. „User Centered Design“ nennt man das oft. Dabei kann dieser User Centered Design Ansatz sogar zu fatalen Fehlentwicklungen führen.

Den ganzen Beitrag lesen »

VN:F [1.9.22_1171]
Rating: 4.5/5 (2 votes cast)

Kategorie: IEC 62304 & Co.
Tags: , , , , ,
1 Kommentar »