EU vs. FDA Unterschiede und Gemeinsamkeiten. Bernhard Fischer
|
|
- Julia Geier
- vor 6 Jahren
- Abrufe
Transkript
1 EU vs. FDA Unterschiede und Gemeinsamkeiten Bernhard Fischer
2 Agenda 1 Grundsätzliche Unterschiede Vergleich der Anforderungen an die SW-Entwicklung Sicherheitsklassifikation Traceability SOUP und OTS 2
3 Regulatorische Anforderungen Die Systeme im Vergleich EU-Richtlinie 93/42/EEC Umsetzung in nationales Recht (Deurschland: MPG) Benannte Stellen CE-Kennzeichung in Eigenverantwortung des Herstellers oder unter Einbeziehung einer Benannten Stelle Marktüberwachung & Meldesystem nationale Behörde Staatliche Gesundheitsbehörde Food and Drug Administration FDA Verantwortlich für Zulassung für Medizinprodukte: Center for Devices and Radiological Health CDRH Gesetzliche Grundlage Food, Drug & Cosmetic Act Medizinprodukte: Kapitel 21CFR Marktüberwachung & Meldeystem FDA 3
4 Regulatorische Anforderungen Hardmonized Standards vs. Recognized Standards EN ISO EN IEC EN IEC EN ISO EN IEC rd Edition IEC IEC ISO IEC 60601: FDA erkennt die 2 nd und 3 rd Edition (seit März 2010) an, aber Nationale Abweichungen für USA Aber für NRTL wird derzeit noch die 2 nd Edition benötig 4
5 Regulatorische Anforderungen Risikomanagement EN ISO 14971:2012 ISO TR ISO 14971:2007 ISO TR AAMI TIR 64 5
6 Regulatorische Anforderungen Gebrauchstauglichkeit EN IEC (EN IEC ) IEC ersetzt ANSI AAMI HE74 ANSI AAMI HE75:2009 Medical Device Use-Safety: Incorporating Human Factors Engineering into Risk Management Do It By Design: An Introduction to Human Factors in Medical Devices 6
7 Agenda 1 Grundsätzliche Unterschiede Vergleich der Anforderungen an die SW-Entwicklung Sicherheitsklassifikation Traceability SOUP und OTS 7
8 Der SW-Entwicklungsprozess Qualitätsmanagementsystem SW-Wartungs-/ Änderungsprozess SW-Sicherheitsklassifizierung IEC SW-Entwicklungsprozess SW-Problemlösungs prozess SW-Konfigurationsmanagement SW-Risikomanagementprozess 8
9 Aktivitäten des SW-Entwicklungsprozess Anforderungs- 5.1 Planung analyse 5.2 Funktionale SW-System anforderungen Spezifikation 5.3 Software- Architektur 5.4 Software- Design 5.8 Akzeptanztest Freigabe 5.7 SW- Systemtest Systemtest 5.6 Integrations Integrationstest Test 5.5 Verifikation Modulttest SW-Einheit 5.5 Implementierung 9
10 Dokumentationsmodell nach IEC Anforderungs- 5.1 Planung analyse 5.2 Funktionale SW-System anforderungen Spezifikation 5.3 Software- Architektur 5.4 Software- Design 5.8 Akzeptanztest Freigabe 5.7 SW- Systemtest Systemtest 5.6 Integrations Integrationstest Test 5.5 Verifikation Modulttest SW-Einheit 5.5 Implementierung 10
11 FDA on Software The vast majority of software problems are traceable to errors made during the design and development process. Software is complex. Even short programs can be very complex and difficult to fully understand. Testing alone cannot fully verify that software is complete and correct. Unlike some hardware failures, software failures occur without advanced warning. Because software can be changed very easily, software and non-software professionals tend to believe that software problems can be corrected easily. Insignificant changes in software code can create unexpected and very significant problems elsewhere in the software program.
12 Entwicklungsprozess nach FDA 12
13 Guidance-Dokumente der FDA Design Control Guidance for Medical Device Manufacturers General Principles of Software Validation - Final Guidance for Industry and FDA Staff Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices Guidance for Off-the-Shelf Software Use in Medical Devices
14 Principles of Software Validation Work within the environment of an established software life cycle Focus on preventing the introduction of defects into the software (not removing them during tests) Use a risk based approach to identify the necessary V&V coverage Whenever software is changed, a validation analysis shall be conducted to determine the extent and impact of that change on the entire software system 14
15 Entwicklungsprozess im Vergleich (1) Regulatorische Anforderungen QM-System nach ISO Erfordert ein Risikomanagement nach ISO Erfordert ein Usability-Prozess nach IEC Erfordert einen Software-Lebenszyklus nach ISO Umfang der notwendigen Aktivtäten und Dokumentation nach der Sicherheitsklasse QM-System nach 21 CFR 820. ISO ist ein recognized standard Usability ist Guidance-Dokumenten beschrieben, IEC ist ein recognized standard Softwareentwicklung ist in General Principles of SW Validation beschrieben 15 Umfang der einzureichenden Dokumentation nach dem Level of Concern
16 Entwicklungsprozess im Vergleich (2) Notwendige Aktivitäten Planung der Entwicklungsaktivitäten Ermittlung und Dokumentation der SW-Anforderungen Festlegung einer Architektur und einer Design in Abhängigkeit vo Implementierung und Verifikation der SW-Einheiten Integration und Verifizierung der Integration Verifizierung des SW-Systems Planung der Entwicklungsaktivitäten Ermittlung und Dokumentation der SW-Anforderungen Festlegung einer Architektur und einer Design Implementierung und Verifikation der SW-Einheiten Integration und Verifizierung der Integration Verifizierung des SW-Systems 16
17 Entwicklungsprozess im Vergleich (3) Planung der Entwicklungsaktivitäten Erstellung eines Plans für Softwareentwicklung Der Plan enthält Referenzen auf die Systementwicklung Den anzuwenden Entwicklungsprozess mit Eingaben und Ausgaben Der Plan enthält Angaben zu eingesetzten Standards, Verfahren und Werkzeugen Der Plan enthält Angaben zur Integration, Verifikation, zum Konfigurations- und Risikomanagement Erstellung eines Plans für die Softwareentwicklung Festlegung wichtiger Qualitätseigenschaften Den anzuwenden Entwicklungsprozess mit Eingaben und Ausgaben Rollen und Verantwortlichkeiten für jede Aufgabe Risikomanagement und Gebrauchstauglichkeit 17
18 Entwicklungsprozess im Vergleich (4) Softwareanforderungen Erstellung und Dokumentation von SW-Anforderungen, die von Systemanforderungen abgeleitet sind Einbeziehen von Risikokontroll-Maßnahmen in die Software-Anforderungen Die SW-Anforderungen beinhalten insbesondere funktionale und nicht-funktionale Anforderungen, Eingaben und Ausgaben sowie Gebrauchstuaglichkeitsanforderungen. Dokumentation der Anforderungen an die Software, einschliesslich funktionaler-, Leistungs-, Schnittstellen-, Design- und anderer Anforderungen an die Software. Einbeziehen von Sicherheitsanforderungen, die aus der Risikoanalyse herrühren Ein Verfahren, wie mit unvollständigen, unklaren und widersprüchlichen Anforderungen umgegangen wird. 18
19 Entwicklungsprozess im Vergleich (5) Architektur und (Detailed) Design Entwicklung einer Architektur das für die Schnittstellen zwischen den Software-Komponenten Spezifikation der SOUP-Komponenten Weitere Unterteilung der Komponentne in SW- Einheiten und Beschreibung der SW-Einheiten und deren Schnittstellen Verifizierung von Architektur und Design SW-Architektur, als detaillierte Zerlegung in funktionale Einheiten und SW-Moduel, einschliesslich einer Architektur-Übersicht, die die Beziehungen zwischen den wichtigen funktionalen Einheiten erläutert, Eine Beschreibung wie die Anforderungen implementiert werden ( Design ), die es erlaubt festzustellen, ob die Anforderungen angemessen umgesetz wurden (in terms of intended use, functionality, safety, and effectiveness) 19
20 Entwicklungsprozess im Vergleich (6) Implementierung und Verifizierung von SW-Einheiten Implementierung jeder Software-Einheit Festlegung eines Verifizierungsprozesses für die Software-Einheiten Festlegung von Akzeptanzkriterien für die Software- Einheiten Verifizieren der Software-Einheiten Implementierung aller im Design identifizierten Elemente Beschreibung der notwendigen Verifizierungsaktivitäten Spezifikation der auf Unit -Ebene durchzuführenden Tests einschliesslich pass/fail-kriterien, sowie Dokumentation der Ergebnisse durch 20
21 Entwicklungsprozess im Vergleich (7) Integration und Verifizierung der Integration und des Systems Integration des Systems und Verifizierung der korrekten Integration des Systems sowie des integrierten Systems Festlegung von Prüfungen für Software-Anforderungen Verifizierung der Software-System Durchführung von Regressionstests, soweit erforderlich Integration der Software-Elemente zu einem SW-Systems Beschreibung der notwendigen Verifizierungsaktivitäten Spezifikation der auf der Integrations- und Systgemebene durchzuführenden Tests einschliesslich pass/fail-kriterien, sowie Dokumentation der Ergebnisse Durchführung von Regressionstests, soweit erforderlich 21
22 Vorläufiges Ergebnis Obwohl die Vorgaben für die Softwareentwicklung durch die EU und die FDA aus anderen Quellen stammen, unterscheiden sie sich nicht grundsätzlich. Die Vorgaben für die verschiedene Aktivitäten unterschieden sich zwar im Detail, es scheint aber grundsätzlich kein Hindernis für einen gemeinsamen Entwicklungsprozess vorzuliegen. 22
23 Agenda 1 Grundsätzliche Unterschiede Vergleich der Anforderungen an die SW-Entwicklung Sicherheitsklassifikation Traceability SOUP und OTS 23
24 Der SW-Entwicklungsprozess Qualitätsmanagementsystem SW-Wartungs-/ Änderungsprozess SW-Sicherheitsklassifizierung IEC Entwicklungsprozess SW-Problemlösungs prozess SW-Konfigurationsmanagement SW-Risikomanagementprozess 24
25 Sicherheitsklassen nach IEC Klasse A: Keine Verletzung oder Schädigung der Gesundheit ist möglich. Klasse B: Keine schwere Verletzung ist möglich. Klasse C: Tod oder schwere Verletzung ist möglich. 25
26 Level of Concern (1) Minor: If failures or latent design flaws are unlikely to cause any injury to the patient or operator. Moderate: If a failure or latent flaw could directly or indirectly result minor injury to the patient or operator Major: If a failure or latent flaw could directly or indirectly result in death or serious injury to the patient or operator. 26
27 Level of Concern (2) Der Level of Concern betrifft nur den Umfang der 510(k)-Submission nicht den für die Compliance notwendige Dokumentation! Der Level of Concern soll vor jeder risikominimierende Maßnahme festgelgt werden. Der Level of Concern gilt für daß gesamte SW-System. Ein unterschiedliche Kategorisierung von Komponenten ist nicht möglich! 27
28 FDA The level of confidence, and therefore the level of software validation, verification, and testing effort needed, will vary depending upon the safety risk (hazard) posed by the automated functions of the device. Konsequenz: Man muss und soll - nicht alle SW- Funktionen bzw. SW-Komponenten gleich behandeln!
29 Was wird für Klasse A verlangt? Kapitel 5.1: Planung der Software-Entwicklung Kapitel 5.2: Analyse der Software-Anforderungen Kapitel 5.5: Implementierung und Verifizierung der Software-Einheiten Kapitel 5.8: Software-Freigabe Erinnerung: Es ist keine Verletzung oder Schädigung der Gesundheit möglich 29
30 Ist die Sicherheitsklasse A sinnvoll? Anforderungen der FDA in «Guidance for the Content of Premarket Submissions» überwiegend ignoriert Anforderungen der FDA in «General Principles of Software Validation» überwiegend ignoriert Keine Anforderungen aus , Kapitel 14 Aus der Sicht des Software-Engineering: Unsinn! 30
31 Sicherheitsklassifizierung (1) Vergleich Sicherheitsklasse A und Minor Level of Concern Planung der Software-Entwicklung Dokumentation der Sicherheitsklasse Dokumentation Software-Anforderungen Implementierung der Software-Einheiten Traceability zwischen Systemanforderungen und SW- Anforderungen Planung der Software-Entwicklung Level of Concern statement Übersicht über die Software-Anforderungen (Verifizierung der Software-Systems) Traceability zwischen Anforderungen, Architektur/Design, identifizierte Gefährdungen, Risikontrollmaßnahmen und V&V Aktivitäten 31
32 Sicherheitsklassifizierung (2) Vergleich Sicherheitsklasse B und Moderate Level of Concern Planung der Software-Entwicklung Dokumentation der Sicherheitsklasse Analyse der Software-Anforderungen Architektur und Design des Software-Systems Implementierung und Verifizierung der Software-Einheiten Verifizierung der Software auf Integrations- und Systembene Traceability Planung der Software-Entwicklung Level of Concern statement Vollständige Software-Anforderungen Architektur und Design des SW-Systems (Verifizierung der Software auf Unit-, Integrations- und Systembene) 32 Traceability
33 Sicherheitsklassifizierung (3) Vergleich Sicherheitsklasse C und Major Level of Concern Planung der Software-Entwicklung Dokumentation der Sicherheitsklasse Analyse der Software-Anforderungen Architektur und Design des Software-Systems ++ Implementierung und Verifizierung der Software-Einheiten ++ Verifizierung der Software auf Integrations- und Systembene Traceability Planung der Software-Entwicklung Level of Concern statement Vollständige Software-Anforderungen Architektur und Design des SW-Systems Verifizierung der Software auf Unit-, Integrations- und Systemebene 33 Traceability
34 Agenda 1 Grundsätzliche Unterschiede Vergleich der Anforderungen an die SW-Entwicklung Sicherheitsklassifikation Traceability SOUP und OTS 34
35 Traceability Anforderungen der FDA (1) The Traceability Analysis links together product requirements, design specifications and testing requirements. The Traceability Analysis also ties together identified hazards with the implementation and the testing of the mitigations. Nach: Content of Premarket Submission for SW 35
36 Traceability Anforderungen der FDA (2) SW requirement shall be traceable to system requirements SW requirement shall be traceable to system requirements and risk analysis results A traceability analysis shall verify, that the sw design implements all sw requirements A source code traceability analysis is important to verify, that all code is linked test specifications and test procedures A tracebility analysis should be used to ensure, that (test) coverage is achieved between Unit Tests to Detailed Design Integration Test to High Level Design System Tests to SW Requirements Nach: General Principles of SW Validation 36
37 Anforderungen an die Traceability (1) Traceability zwischen Anforderungen und Verifikationen Zwischen Systemanforderungen zu SW-Anforderungen Zwischen SW-Anforderungen zu SW-System-Tests Zwischen Systemanforderungen zu SW-Anforderungen Zwischen SW-Anforderungen zu SW-System-Tests (Zwischen SW-Anforderungen zu Architektur, Design und Code) (Zwischen Architektur und Integrationstest) (Zwischen Detailed Design, Code und Unit-Tests) 37
38 Anforderungen an die Traceability (2) Traceability zwischen Gefährdungen und Risikokontrollmaßnahmen Zwischen der Gefährdungssituation, der spezifischen Ursache und der zugehörigen Risikokontrollmaßnahme Zwischen der Risikokontrollmaßnahme und den zugehörigen SW-Anforderungen und der SW- Komponente, die die Maßnahme implementiert Zwischen der Risikokontrollmaßnahme und der zugehörigen Verifizierung Zwischen der Gefährdung zu der zugehörigen Risikokontrollmaßnahme Zwischen der Risikokontrollmaßnahme und der Implementierung der Risikokontrollmaßnahme Zwischen der Risikontrollmaßnahme und zugehörigen Verifizierung Inhaltlich identisch zu den Anforderungen der EU 38
39 Agenda 1 Grundsätzliche Unterschiede Vergleich der Anforderungen an die SW-Entwicklung Sicherheitsklassifikation Traceability SOUP und OTS 39
40 Definition von SOUP und OTS Die IEC definiert Software of unknown provenance (SOUP als): Software-Komponente, die bereits entwickelt wurde, und allgemein verfügbar ist, und die nicht entwickelt wurde, um in das Medizinprodukt integriert zu werden, oder bereits fertig entwickelte Software, für die angemessene Aufzeichnungen zum Entwicklungsprozess nicht verfügbar sind. Die FDA definiert Off-The-Shelf-Software (OTS- Software) als A generally available software component, used by a medical device manufacturer, for which the manufacturer cannot claim complete software life cycle control. 40
41 Ähnlichkeiten und Unterschiede (1) OTS ist nicht auf den Einsatz in Medizinprodukten beschränkt. Und wenn dieser Software benutzt wird, to design, build and test the software und von anderen Herstellern vertrieben wird, dann fällt sie unter den Begriff OTS- Software. (s. Kapitel 6 der General Principles on Software Validation Das ist dann aber keine SOUP mehr. Ein typisches Beispiel ist jegliche Prozess-Software von anderen Herstellern. 41
42 Ähnlichkeiten und Unterschiede (2) SOUP muss nicht notwendig von einem anderen Hersteller stammen. Alle Software-Komponenten, die nicht allgemein verfügbar sind, etwa diejenigen, die der Medizinproduktehersteller selbst aber für einen anderen Zweck entwickelt hat und diese jetzt in das Medizingerät integrieren möchte, sind SOUP. Eine solche Komponente ist aber kein OTS. 42
43 Ähnlichkeiten und Unterschiede (3) Es gibt SOUP, die auch OTS ist, genauer: Alle allgemein verfügbaren Komponenten, die nicht dafür entwickelt wurden Teil des zu entwickelnden Medizingerätes zu werden, und über dessen Entwicklungsprozess der Hersteller daher auch keine Kontrolle hat sind sowohl SOUP als auch OTS, wenn der Hersteller des Medizingerätes sie in das Gerät integriert. 43
44 Thank you! Fischer Consulting GmbH Bernhard Fischer Waldstr. 106 D Bochum 44
Medizinische Software
510(k) Software-Unit FDA Traceability Segregation Medizinische Software Software-Item SOUP Safety Classification Risikomanagement für So1ware: Die Kunst der Sicherheitsklassifizierung Bernhard Fischer
MehrNormerfüllung in der Praxis am Beispiel "Tool Qualification" Dr. Anne Kramer, sepp.med gmbh
Normerfüllung in der Praxis am Beispiel "Tool Qualification" Dr. Anne Kramer, sepp.med gmbh Über uns Mittelständischer IT-Service Provider 30 Jahre Industrieerfahrung Unsere Referenzen Medizintechnik Pharma
MehrHow to Survive an Audit with Real-Time Traceability and Gap Analysis. Martin Kochloefl, Software Solutions Consultant Seapine Software
How to Survive an Audit with Real-Time Traceability and Gap Analysis Martin Kochloefl, Software Solutions Consultant Seapine Software Agenda Was ist Traceability? Wo wird Traceability verwendet? Warum
MehrUsability Validierung von medizinischer Software durch Usability-Tests. Michael Engler
Usability Validierung von medizinischer Software durch Usability-Tests Michael Engler Fahrplan Warum Usability-Tests? Was ist zu tun? Was ist zu beachten? 25.06.2013 Michael Engler IT-Consulting 2 Warum
MehrFunktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,
Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional
MehrALM Days 2012. Normenkonforme Software-Entwicklung für Medizinprodukte mit dem Microsoft Team Foundation Server
ALM Days 2012 ALM Days 2012 Normenkonforme Software-Entwicklung für Medizinprodukte mit dem Microsoft Team Foundation Server Dipl.- Ing. Birgit Stehlik, Dipl.-Ing. Sven Wittorf, M.Sc. 1 Medizinische Software
MehrÜbersicht. Normung von Software in der Medizin. Vorstellung der DKE. Vorstellung der Normungsgremien. Normen im Bereich Software.
Normung von Software in der Medizin Übersicht Vorstellung der DKE Vorstellung der Normungsgremien Normen im Bereich Software Zukunftstrends 20.09.2013/1 Vorstellung der DKE Gemeinnütziger Verband ohne
MehrI-Q SCHACHT & KOLLEGEN QUALITÄTSKONSTRUKTION GMBH ISO 26262:2011. Tabellen mit ASIL Zuordnungen
I-Q SCHACHT & KOLLEGEN QUALITÄTSKONSTRUKTION GMBH ISO 26262:2011 Tabellen mit ASIL Zuordnungen 1. Die Tabellen in der Norm (mit ASIL Zuordnung) Ein wesentlicher Bestandteil der Norm sind die insgesamt
MehrPOST MARKET CLINICAL FOLLOW UP
POST MARKET CLINICAL FOLLOW UP (MEDDEV 2.12-2 May 2004) Dr. med. Christian Schübel 2007/47/EG Änderungen Klin. Bewertung Historie: CETF Report (2000) Qualität der klinischen Daten zu schlecht Zu wenige
MehrDOT. implantsource. Qualitätsmanagement. Innovative Produkte für die Medizin. Prof. Dr. H.- G.Neumann DOT
DOT implantsource Qualitätsmanagement Innovative Produkte für die Medizin Prof. Dr. H.- G.Neumann DOT Medizinprodukt - Begriff Medizinprodukte Medizinprodukte nach 3 MPG sind alle einzeln oder miteinander
MehrISO 15504 Reference Model
Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define metrics Pre-review Review yes Release
Mehrwww.pwc.com FATCA implementieren in der Schweiz vom Projekt bis zum operativen Prozess SVV Präsentation 4. April 2013
www.pwc.com FATCA implementieren in der Schweiz vom Projekt bis zum operativen Prozess Präsentation 4. Agenda 1. Einführung 2. FATCA-Hauptaufgaben 3. Versicherer in der Schweiz und FATCA 4. Implementierungsaspekte
MehrGenerische Normen zur Funktionalen Sicherheit im Maschinenbau. IEC und ISO 13849
Generische Normen zur Funktionalen Sicherheit im Maschinenbau IEC 62061 und ISO 13849 Thomas Bömer, VDE/DKE-TAGUNG 20 JAHRE IEC 61508 22.03.2017 Politik nach dem Merging IEC/TC44 und ISO/TC199 treffen
MehrEntwicklung einer sensorlosen Motorregelung für Dentalbohrer nach IEC Dr. Michael Schwarz
Entwicklung einer sensorlosen Motorregelung für Dentalbohrer nach IEC 62304 Dr. Michael Schwarz Agenda ITK Engineering AG Von der Idee bis zum Produkt Überblick und Motivation Herausforderungen sensorlose
MehrIEC 62304. Was bringt das Amendment 1. Matthias Hölzer-Klüpfel
IEC 62304 Was bringt das Amendment 1 Matthias Hölzer-Klüpfel Regulatorische Grundlagen Wann ist Software ein Medizinprodukt? für die Entwicklung medizinischer Software Medizinprodukt, MDD Novelle 2007
MehrSW-Tests bei Siemens Med MR
SW-Tests bei Siemens Med MR Testprozess eines großen Embedded Systems 2 SIEMENS AG Medical Solutions GG MR Das Geschäftsgebiet MR Ca. 600 Beschäftigte Ca. 700 Systeme pro Jahr Ca. 1 Mrd. Euro Umsatz 3
MehrSicherheitsnormen im Umbruch Revision der EN 5012X-Suite
Sicherheitsnormen im Umbruch Revision der EN 5012X-Suite Stephan Griebel Siemens AG Infrastructure & Cities Sector Mobility and Logistics Division Siemens AG 2008 2012 Inhalt Revision der EN 5012X-Suite
MehrManagement Hardware Software
Management Hardware Software (ISO 26262, Reliability IEC Engineering 61508, ) TÜV NORD Systems GmbH & Co. KG Branch South Functional Safety Funktionale Halderstr. Sicherheit 27 D-86150 Augsburg TÜV NORD
MehrDarstellung und Anwendung der Assessmentergebnisse
Process flow Remarks Role Documents, data, tool input, output Important: Involve as many PZU as possible PZO Start Use appropriate templates for the process documentation Define purpose and scope Define
Mehrvii Inhaltsverzeichnis 1 Einleitung 1 2 Rechtliche Grundlagen 5
vii 1 Einleitung 1 2 Rechtliche Grundlagen 5 2.1 Die Rechtslage in Europa.................................. 5 2.1.1 Definition eines Medizinproduktes.................... 5 2.1.2 Richtlinien, Gesetze und
MehrISO / FuSi Funktionale Sicherheit Road Vehicle - Functional Safety
I-Q SCHACHT & KOLLEGEN QUALITÄTSKONSTRUKTION GMBH ISO 26262 / FuSi Funktionale Sicherheit Road Vehicle - Functional Safety Seminar-Inhalte ISO 26262 / FuSi - Funktionale Sicherheit Road Vehicle - Functional
MehrProduct Lifecycle Manager
Product Lifecycle Manager ATLAS9000 GmbH Landauer Str. - 1 D-68766 Hockenheim +49(0)6205 / 202730 Product Lifecycle Management ATLAS PLM is powerful, economical and based on standard technologies. Directory
Mehrprorm Budget Planning promx GmbH Nordring Nuremberg
prorm Budget Planning Budget Planning Business promx GmbH Nordring 100 909 Nuremberg E-Mail: support@promx.net Content WHAT IS THE prorm BUDGET PLANNING? prorm Budget Planning Overview THE ADVANTAGES OF
MehrErfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen.
Stefan Topp Honeywell International SARL 16. Februar 2012 Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. 1 Agenda Hintergruende Der Auswahlprozess Ausrollen von
MehrDas "Competence Center Pharma" stellt sich vor
Das "Competence Center Pharma" stellt sich vor Unsere Leistungen Computervalidierung Prozeßvalidierung Anlagenvalidierung Compliance Inspektionen Qualitätsmanagement (ISO 9000, 13485, KAIZEN) Instandhaltungsmanagement
MehrSecurity for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443
Security for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443 Roadshow INDUSTRIAL IT SECURITY Dr. Thomas Störtkuhl 18. Juni 2013 Folie 1 Agenda Einführung: Standard IEC 62443
MehrTMF projects on IT infrastructure for clinical research
Welcome! TMF projects on IT infrastructure for clinical research R. Speer Telematikplattform für Medizinische Forschungsnetze (TMF) e.v. Berlin Telematikplattform für Medizinische Forschungsnetze (TMF)
MehrSPiCE und Test: Was hat das denn miteinander zu tun?
SPiCE und Test: Was hat das denn miteinander zu tun? TAV Düsseldorf 15./16.2.2007 Arbeitskreis Test eingebetteter Systeme Dr. Uwe Hehn Uwe.Hehn@methodpark.de Gliederung Reifegradmodelle Übersicht über
MehrCustomer-specific software for autonomous driving and driver assistance (ADAS)
This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs
MehrISO SPICE Erste Eindrücke
ISO 15504 SPICE Erste Eindrücke Klaus Franz Muth Partners GmbH, Wiesbaden 06122 5981-0 www.muthpartners.de klaus.franz@muthpartners.de SPiCE ISO 15504 1 Stand der Dinge 29. Januar 2005 ISO/IEC 15504 PUBLICATION
MehrEntwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist...
Anwendungsbeginn Anwendungsbeginn dieser Norm ist.... Inhalt Einführung... 13 1 Anwendungsbereich... 16 1.1 *Zweck... 16 1.2 *Anwendungsbereich... 16 1.3 Beziehung zu anderen Normen... 16 1.4 Einhaltung...
Mehr3. GI-Workshop EPK 2004 Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten Luxemburg. ARIS meets RUP
3. GI-Workshop EPK 2004 Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten Luxemburg ARIS meets RUP Der ARIS Unified Information System Development Process Martin Plümicke Berufsakademie
MehrTechnische Dokumentation in der Medizintechnik. Hans-Jörg Elsen Varian Medical System Particle Therapy
Technische Dokumentation in der Medizintechnik Hans-Jörg Elsen Varian Medical System Particle Therapy Inhalte Person Varian Medical Systems Particle Therapy Technische Dokumentation bei VMS-PT Anforderungen
MehrInformation Governance - Enabling Information
Information Governance - Enabling Information Dr. Wolfgang Johannsen Frankfurt, den 3. April 2014 Akademische Programme Berufsbegleitende Programme Seminare Executive Education Firmenprogramme & Services
MehrGMP Training Course. EU GMP Requirements. Sterile medicinal product
GMP Training Course 20-21 October 2009 EU GMP Requirements Sterile medicinal product Dr. Martin Melzer Dr. Martin Melzer Pharmacist / GMP Inspector Tel.: + 49 (0) 511 9096 450 martin.melzer@gaa-h.niedersachsen.de
MehrHazards and measures against hazards by implementation of safe pneumatic circuits
Application of EN ISO 13849-1 in electro-pneumatic control systems Hazards and measures against hazards by implementation of safe pneumatic circuits These examples of switching circuits are offered free
MehrRisikominimierung bei der Einführung neuer Produkte und Dienstleistungen im Pflegesektor
Risikominimierung bei der Einführung neuer Produkte und Dienstleistungen im Pflegesektor WiMi-Care Zwischenworkshop Alexander Steffen 04. November 2010 Agenda 01. Einleitung 02. Normen als Grundlage 03.
MehrRequirement: Klar und testbar!
Requirement: Klar und testbar! Definitionen, Merkmale, Beispiele Lukas Kraus, Lead QA Engineer www.bbv.ch bbv Software Services Corp. 1 Ich geh mal fragen was die wollen, und ihr beginnt schon mal zu codieren!!!
MehrISO 15504 Reference Model
Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define
MehrGURUCAD - IT DIVISION CATIA V5 PLM EXPRESS CONFIGURATIONS Hamburg, 16th February 2010, Version 1.0
Engineering & IT Consulting GURUCAD - IT DIVISION CATIA V5 PLM EXPRESS CONFIGURATIONS Hamburg, 16th February 2010, Version 1.0 IT DIVISION CATIA V5 DEPARTMENT Mobile: +49(0)176 68 33 66 48 Tel.: +49(0)40
MehrAm Beispiel eines international tätigen Automotive Lieferanten
Anpassung der Prozesslandschaft an moderne Safety-Anforderungen Am Beispiel eines international tätigen Automotive Lieferanten Inhalt ZKW Group, ZKW Elektronik Safety in Automotive Functional Safety ISO
MehrWhich data and when?
PRO-data for market access in Germany where and when? Frank-Ulrich Fricke PRO-data for market access in Germany where and when? AMNOG the German assessment Which data and when? Requirements to be met Seite
MehrMedizinprodukte Software und medizinische IT-Netzwerke. Martin Zauner
Medizinprodukte Software und medizinische IT-Netzwerke Martin Zauner Studiengang Medizintechnik Lehre: Medizintechnik (Med. Geräte- und Rehabilitationstechnik) Vertiefungen: Medizinische Messtechnik und
MehrNewest Generation of the BS2 Corrosion/Warning and Measurement System
Newest Generation of the BS2 Corrosion/Warning and Measurement System BS2 System Description: BS2 CorroDec 2G is a cable and energyless system module range for detecting corrosion, humidity and prevailing
MehrEntwicklung Safety-relevanter Steuergeräte auf Basis des V-Modells
AUTOMOTIVE INFOKOM MOBILITÄT, ENERGIE & UMWELT LUFTFAHRT RAUMFAHRT VERTEIDIGUNG & SICHERHEIT Entwicklung Safety-relevanter Steuergeräte auf Basis des V-Modells Stephen Norton VMEA 12.11.2015 CoC SAFETY
Mehrp^db=`oj===pìééçêíáåñçêã~íáçå=
p^db=`oj===pìééçêíáåñçêã~íáçå= Error: "Could not connect to the SQL Server Instance" or "Failed to open a connection to the database." When you attempt to launch ACT! by Sage or ACT by Sage Premium for
MehrIDS Scheer Consulting Prozessorientierte SAP-ERP Implementierung mit Industry.Performance READY
IDS Scheer Consulting Prozessorientierte SAP-ERP Implementierung mit Industry.Performance READY Peter Hasmann, zspm Practice Manager SME Business Wien, 26. Juni 2012 Agenda June 26, 2012 3 Von Ihrer Unternehmens-Strategie
MehrHealth Apps, Lifestyle Apps, Medical Apps Unterschiede und Rahmenbedingungen
Health Apps, Lifestyle Apps, Medical Apps Unterschiede und Rahmenbedingungen build.well.being 2017 Andreas Böhler R n B Medical Software Consulting GmbH office@rnb-consulting.at build.well.being 2017 30.
MehrNormenausschüsse in der Labormedizin
Normenausschüsse in der Labormedizin - Überblick - Historie - Konsequenzen - Aktivitäten - Vorteile/Nachteile 9/19/2007 1 Internationale Organisationen im IVD/MD Bereich GHTF (Global Harmonization Task
MehrBrandbook. How to use our logo, our icon and the QR-Codes Wie verwendet Sie unser Logo, Icon und die QR-Codes. Version 1.0.1
Brandbook How to use our logo, our icon and the QR-Codes Wie verwendet Sie unser Logo, Icon und die QR-Codes Version 1.0.1 Content / Inhalt Logo 4 Icon 5 QR code 8 png vs. svg 10 Smokesignal 11 2 / 12
Mehron Software Development Design
Werner Mellis A Systematic on Software Development Design Folie 1 von 22 How to describe software development? dimensions of software development organizational division of labor coordination process formalization
MehrVon Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé
Von Requirements zus gç~åüáãkpåüìäò]èì~äáíóé~êâkçé QualityPark Ihr Partner im Lifecycle Management Process Management Requirements Engineering IT & Development Process Expertise Process Implementation
MehrRequirements-basiertes Testen am Beispiel des NI Requirements Gateways
Requirements-basiertes Testen am Beispiel des NI Requirements Gateways National Instruments VIP Kongress München, M 8. Oktober 2008 Joachim Schulz QualityPark GmbH V-Modell Demands Business Requirement
Mehraqpa Vereinstreffen 15. Okt. 2014, Wien
aqpa Vereinstreffen 15. Okt. 2014, Wien EU-GMP-Richtlinie Part II Basic Requirements for Active Substances used as Starting Materials Dr. Markus Thiel Roche Austria GmbH History ICH Richtlinie Q7 Nov.
MehrKernprozess zur System- und Softwareentwicklung. Logische Systemarchitektur f 1. f 2 f 3. f 4 Funktion. Technische Systemarchitektur SG 1 SG 2 SG 3
Systems Engineering Systems Engineering ist die gezielte Anwendung von wissenschaftlichen und technischen Ressourcen! zur Transformation eines operationellen Bedürfnisses in die Beschreibung einer Systemkonfiguration
MehrDie Rolle des QM-Systems - Forderung und Praxis
Die Rolle des QM-Systems - Forderung und Praxis Inhalt Warum ist ein QM-System für Hersteller von Medizinprodukten so wichtig? Was kann die Basis eines solchen Systems sein? Zusammenfassung FAQs Inhalt
MehrDokumentation (ISO 26514) Prof. Sissi Closs Donnerstag,, 5. November 2009
Der neue ISO-Standard Standard für f r Software- Dokumentation (ISO 26514) Prof. Sissi Closs Donnerstag,, 5. November 2009 ISO/IEC 26514 Software and systems engineering User documentation requirements
MehrTPI NEXT applied for medical. AQSF Fachgruppe Medizintechnik
TPI NEXT applied for medical AQSF Fachgruppe Medizintechnik About b-quality 2 Ziele und Anforderungen von Testprozessen Testprozesse (sollen) - Fehler finden - Schwachstellen aufdecken Anforderungen an
MehrAbbildung 1: Tool-Qualification-Kits für Testwell CTC++ Test Coverage Analyser
Qualification-Kit für Testwell CTC++ In der sicherheitskritischen Softwareentwicklung müssen die im Projekt eingesetzten Werkzeuge zunächst klassifiziert werden (Tool Classification). Diese Klassifizierung
MehrTotal Security Intelligence. Die nächste Generation von Log Management and SIEM. Markus Auer Sales Director Q1 Labs.
Total Security Intelligence Die nächste Generation von Log Management and SIEM Markus Auer Sales Director Q1 Labs IBM Deutschland 1 2012 IBM Corporation Gezielte Angriffe auf Unternehmen und Regierungen
MehrFolie 1. agilemed 2014. Rico Unger 2014 19 Februar. ALM für medizinische Softwareentwicklung WWW.INTLAND.COM
Folie 1 agilemed 2014 ALM für medizinische Softwareentwicklung Rico Unger 2014 19 Februar Kurze Vorstellung Folie 2 Rico Unger 10-jährige Erfahrung im MedTech-Bereich Entwickler von Hardware / embedded
MehrKURZVORSTELLUNG. Ergosign Medical & Pharma Design
KURZVORSTELLUNG Ergosign Medical & Pharma Design UNSER UNTERNEHMEN Mission & Facts Spezialisierter Anbieter von User Interface Design Services Fokus: B2B Anwendungen, Productivity, Anwendungen für Professionals,
MehrHow-To-Do. Communication to Siemens OPC Server via Ethernet
How-To-Do Communication to Siemens OPC Server via Content 1 General... 2 1.1 Information... 2 1.2 Reference... 2 2 Configuration of the PC Station... 3 2.1 Create a new Project... 3 2.2 Insert the PC Station...
MehrKomplexität beherrschen mit Contract Based Design
Komplexität beherrschen mit Contract Based Design Thomas Schütz / PROTOS GmbH P4You-Thementag 5.5.2017 - Bamberg The Problem + = How can we avoid this in complex software and systems? How do we describe
MehrPTS Training Service: Archivierung, Annex 11, Part 11. Annex 11. aus Sicht eines GMP Inspektors
PTS Training Service: Archivierung, Annex 11, Part 11 Annex 11 aus Sicht eines GMP Inspektors Klaus Eichmüller c/o Regierung von Oberbayern ZAB Speyer, 1 Annex 11 Rechtsgrundlagen GS (GMP keine Beeinträchtigung
Mehr1.9 Dynamic loading: τ ty : torsion yield stress (torsion) τ sy : shear yield stress (shear) In the last lectures only static loadings are considered
1.9 Dynaic loading: In the last lectures only static loadings are considered A static loading is: or the load does not change the load change per tie N Unit is 10 /sec 2 Load case Ι: static load (case
MehrWord-CRM-Upload-Button. User manual
Word-CRM-Upload-Button User manual Word-CRM-Upload for MS CRM 2011 Content 1. Preface... 3 2. Installation... 4 2.1. Requirements... 4 2.1.1. Clients... 4 2.2. Installation guidelines... 5 2.2.1. Client...
MehrMedical Apps Anforderungen bei der Konformitätsbewertung Herausforderungen für Hersteller und benannte Stellen
Medical Apps Anforderungen bei der Konformitätsbewertung Herausforderungen für Hersteller und benannte Stellen Dr. Markus Wagner Aktive Medizinprodukte AMP1 Inhalt Stand Alone Software, Mobile Apps Regulatorisches
MehrFred Stay 2013-06-04/05. Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie
Fred Stay 2013-06-04/05 Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie 1. Warum brauchen wir ein FSM 2. Vermeidung/Beherrschung von Fehlern 3. Praxisbeispiel:
MehrEntwicklungsoptimierung mit einem ALM Tool Positionierung mit Fallstudie
Entwicklungsoptimierung mit einem ALM Tool Positionierung mit Fallstudie Gerald Heller Agenda Standortbestimmung ALM Typischer industrieller Setup und Probleme Vorstellung von QualityCenter als ALM tool
MehrWann wird Bildverarbeitungssoftware zum Medizinprodukt? 11. Linzer Forum Medizintechnik November 2014
Wann wird Bildverarbeitungssoftware zum Medizinprodukt? 11. Linzer Forum Medizintechnik November 2014 martin.zauner@fh-linz.at Inhalt Regulatorischer Rahmen für Medizinprodukte (regulatory affairs) Medizinische
MehrCable Tester NS-468. Safety instructions
Cable Tester NS-468 Safety instructions Do not use the cable tester NS-468 if it is damaged. This device is only for use inside dry and clean rooms. This device must be protected from moisture, splash
MehrDer Adapter Z250I / Z270I lässt sich auf folgenden Betriebssystemen installieren:
Installationshinweise Z250I / Z270I Adapter IR USB Installation hints Z250I / Z270I Adapter IR USB 06/07 (Laden Sie den Treiber vom WEB, entpacken Sie ihn in ein leeres Verzeichnis und geben Sie dieses
MehrKeynote Der offene Ansatz: Open Source basiertes ALM ganz praktisch
Keynote ALMconf 2010 in Stuttgart 26. bis 28. Oktober 2010 Thomas Obermüller elego Software Solutions GmbH - 2010 1 Welcome & Outline Open Source basiertes ALM ganz praktisch Agenda Application Lifecycle
MehrTechnische Dokumentation in der Medizintechnik. Hans-Jörg Elsen Varian Medical System Particle Therapy
Technische Dokumentation in der Medizintechnik Hans-Jörg Elsen Varian Medical System Particle Therapy Über mich Studium Elektrotechnik und Germanistik an der RWTH Aachen seit gut 20 Jahren in der Technischen
MehrHIR Method & Tools for Fit Gap analysis
HIR Method & Tools for Fit Gap analysis Based on a Powermax APML example 1 Base for all: The Processes HIR-Method for Template Checks, Fit Gap-Analysis, Change-, Quality- & Risk- Management etc. Main processes
MehrXML Template Transfer Transfer project templates easily between systems
Transfer project templates easily between systems A PLM Consulting Solution Public The consulting solution XML Template Transfer enables you to easily reuse existing project templates in different PPM
MehrZiele und Tätigkeiten von Architekten
Ziele und Tätigkeiten von Architekten Definition Software Architektur o A software architecture provides a model of a whole software system that is composed of internal behavioral units (i.e. components)
MehrGAUSS towards a common certification process for GNSS applications using the European Satellite System Galileo
GAUSS towards a common certification process for GNSS applications using the European Satellite System Galileo Matthias Grimm, Dr. Michael Meyer zu Hörste Vortragstitel > 11. Juni 2010 > Folie 1 Agenda
MehrUnternehmensweite IT Architekturen
Unternehmensweite IT Architekturen Part 1: IT Systems Architecture, Roles and Responsibilities of IT Architects Part 2: Solution Architecture, based on a practical Case Study Part 3: SOA (Service Oriented
MehrFachkrä(e*mit*Leidenscha(*für*Details*! Specialisterne!Deutschland! Ma2hias!Prössl!! 64.!Roundtable!;!Münchner!UnternehmerKreis! IT! 18.
Fachkrä(e*mit*Leidenscha(*für*Details*! Specialisterne!Deutschland! Ma2hias!Prössl!! 64.!Roundtable!;!Münchner!UnternehmerKreis! IT! 18. April 2013 Menschen mit einer Autismus Spektrum Störung (ASS) sind
MehrRisk-Managements for Installation, Maintenance and Reprocessing of Medical Devices
Risk-Managements for Installation, Maintenance and Reprocessing of Medical Devices Laws, Guidelines and Standards Medizinproduktegesetz (MPG) Medizinprodukte-Betreiberverordnung (MBetreibV) Sicherheitsplanverordnung
MehrGURUCAD - IT DIVISION Discover Configuration (DIC) for Academics Hamburg, 16th February 2010, Version 1.0
Engineering & IT Consulting GURUCAD - IT DIVISION Discover Configuration (DIC) for Academics Hamburg, 16th February 2010, Version 1.0 IT DIVISION CATIA V5 DEPARTMENT Mobile: +49(0)176 68 33 66 48 Tel.:
MehrLOC Pharma. Anlage. Lieferantenfragebogen Supplier Questionnaire. 9. Is the warehouse temperature controlled or air-conditioned?
Please complete this questionnaire and return to: z.h. Leiter Qualitätsmanagement info@loc-pharma.de Name and position of person completing the questionnaire Signature Date 1. Name of Company 2. Address
MehrVDE Prüf- und Zertifizierungsinstitut
VDE Prüf- und Zertifizierungsinstitut VDE Prüf- und Zertifizierungsinstitut GmbH Merianstraße 28 63069 Offenbach Microchip Technology Inc. Vestre Rosten 79 7075 TILLER Norway Offenbach, 2017-07-27 Ihr
MehrQM Neuerungen und Trends PPAP Fourth Edition
QM Neuerungen und Trends PPAP Fourth Edition Oktober 2007 by QM Neuerungen und Trends Teil 1: PPAP Fourth Edition die wichtigsten Änderungen im Überblick Oktober 2007 by PPAP Fourth Edition Änderungen
Mehriid software tools QuickStartGuide iid USB base driver installation
iid software tools QuickStartGuide iid software tools USB base driver installation microsensys Nov 2016 Introduction / Einleitung This document describes in short form installation of the microsensys USB
MehrBPA Suite und SOA - vom fachlichen Prozessmodell zur Anwendung. Bernhard Fischer-Wasels Leitender Systemberater
BPA Suite und SOA - vom fachlichen Prozessmodell zur Anwendung Bernhard Fischer-Wasels Leitender Systemberater Safe Harbor Statement The following is intended to outline our general product direction.
MehrHow to develop and improve the functioning of the audit committee The Auditor s View
How to develop and improve the functioning of the audit committee The Auditor s View May 22, 2013 Helmut Kerschbaumer KPMG Austria Audit Committees in Austria Introduced in 2008, applied since 2009 Audit
MehrTest Report. Test of resitance to inertia effects of Zirkona Backwall. Sled Test (Frontal Impact) 20 g / 30 ms
Test Report Test of resitance to inertia effects of Zirkona Backwall Sled Test (Frontal Impact) 20 g / 30 ms This report serves solely as a documentation of test results. 93XS0002-00_TdC.doc Page 1 1.
MehrAusblick auf die Medizinprodukte Verordnung - Klinische Prüfungen
Ausblick auf die Medizinprodukte Verordnung - Klinische Prüfungen Dr. Ilona Reischl Institute Überwachung BASG/AGES Austrian Agency for Health and Food Safety GmbH Medizinprodukte Die bisher unterschiedlichen
MehrGAMP5. Grundzüge und Änderungen zu GAMP4. Siemens-Pharma-Forum, 17.04.2008, Muttenz, Schweiz
Siemens-Pharma-Forum, 17.04.2008, Muttenz, Schweiz GAMP5 Grundzüge und Änderungen zu GAMP4 Hartmut Hensel Hochschule Harz Wernigerode +49 3943 659 313 hhensel@hs-harz.de 1 Inhalt der Präsentation GAMP5
MehrAbschnitt 1. BPM als Lingua franca. Management, Fachbereiche und IT Ist BPM ein Weg zur (Auf-)Lösung der Sprachbarriere?
BPM als Lingua franca Management, Fachbereiche und IT Ist BPM ein Weg zur (Auf-)Lösung der Sprachbarriere? Abschnitt 1 All trademarks used are the property of their respective owners Lingua franca Language
MehrSupplier Questionnaire
Supplier Questionnaire Dear madam, dear sir, We would like to add your company to our list of suppliers. Our company serves the defence industry and fills orders for replacement parts, including orders
MehrAutomotive SPICE 3.0 What`s new? tecmata GmbH. Flörsheim, tecmata GmbH. tecmata GmbH
Automotive SPICE 3.0 What`s new? tecmata GmbH Flörsheim, 20.09.2016 Kernkompetenz Systemtest Requirements- Engineering Implementation Integrationstest Funktionale Sicherheit Embedded Software Engineering
MehrSafer Software Formale Methoden für ISO26262
Safer Software Formale Methoden für ISO26262 Dr. Stefan Gulan COC Systems Engineering Functional Safety Entwicklung Was Wie Wie genau Anforderungen Design Produkt Seite 3 Entwicklung nach ISO26262 Funktionale
MehrImplementierung von IEC 61508
Implementierung von IEC 61508 1 Qualität & Informatik -www.itq.ch Ziele Verständnis für eine mögliche Vorgehensweise mit IEC 61508 schaffen Bewusstes Erkennen und Behandeln bon Opportunitäten unmittelbaren
MehrDisclaimer SAP SE or an SAP affiliate company. All rights reserved. Public
Disclaimer Die Informationen in dieser Präsentation sind vertraulich und urheberrechtlich geschützt und dürfen nicht ohne Genehmigung von SAP offengelegt werden. Diese Präsentation unterliegt weder Ihrem
MehrSicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte
Sicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte F. Seidel, BfS Salzgitter (Juli 2002) 1) Begriffsbestimmung (Vergleich unter Nutzung nationaler und internationaler
MehrHealth Software vs. Medical Apps
Health Software vs. Medical Apps Kontakt: Beim Strohhause 17 20097 Hamburg Germany Tel.: +49-40-66 87 88-0 Fax: +49-40-66 87 88-199 E-Mail: info@prosystem-ag.com Vorstand: Prof. Dr. Jürgen Stettin Dipl.-Ing.
Mehr