CPU für medizinische Anwendungen

grob kann man 3 Gruppen einteilen:
-Geräte, die zwar im mediz. Bereich eingesetzt werden, trotzdem aber
keine weiteren Anforderungen haben müssen, kein Patient-Kontakt.
-Geräte mit direktem Patientenkontakt (und wenn es nur ein einfacher
Blutdruckmesser ist), es muss unter allen Umständen gewährleistet sein,
dass dem Patienten kein Schaden geschehen kann, Ausfall oder
Fehlfunktion tolerierbar
-live-support Systeme, naja - das sagt alles. Viele Chiphersteller
schliessen die Verwendung ihrer Standard-Chips hierfür explizit aus.

Was genau hast du vor? Das kann ein beschwerlicher (und teurer) Weg
werden.

>>live-support Systeme, naja - das sagt alles. Viele Chiphersteller
schliessen die Verwendung ihrer Standard-Chips hierfür explizit aus.

nicht nur im medizinischen!!!
ich arbeite für eine rüstungsfirma...
schonmal da teile aus dem nicht europa/amerikanischen raum (wie z.b
fujitsu, toschiba,...) bezogen??? die verweigern selbs die samples,
wenn sie nur den briefkopf lesen...

Es ist im Moment eine Vorentwicklung für ein Diagnose- und
Therapiegerät. Die Anwendung muss schnell genug sein, um allerlei
Schnittstellen zu realisieren. Eigentlich könnte man einen FPGA nehmen,
aber ich kann keinen programmieren. Ich kenne mich leider auch bei CPUs
nicht genügend aus - kann nur C++ programmieren und kenne den
GNU-Compiler recht gut. Daher tendiere ich eher zu einem Controller, da
ich dafür selber entwickeln kann. Zulassung oder so ist erstmal kein
Thema, weil es ein Prototyp ist, der nicht an Patienten getestet wird.

Mir geht es darum, ein Beispiel zu erhaschen und ein paar Tipps zu
bekommen, z.B. welche Controller medizinisch "zertifiziert" sind.

Das Problem ist hinterher nicht nur der Controller, sondern auch die
Software muß zertifiziert werden.

Aber was bringt es einen ein funktionierender Prototyp, wenn er später
nicht zugelassen werden kann?

Gerade im medizinischem Bereich ist auch die verwendete
Programmiersprache sehr wichtig, hab mal gehört, dass da fast alles
noch mit Pascal oder BASIC gemacht wird, weil diese Sprachen sicherer
by Design sind, als z.B. C oder C++. Und im Militärischem Bereich wird
sehr viel mit Ada gemacht, wol auch wegen der Echzeiterweiterungen, die
diese Sprache wol hat.
Gruß, Thomas

Hallo!
Ich arbeite als QMB im Bereich Medizinprodukte.
Der Controller muß nicht zertifiziert sein, sondern die
Bauteile-Zulieferer.
Die Software muß verifiziert und validiert werden.
Ebendso muß ein QM-System eingeführt werden, damit Medizinprodukte
verkauft und CE gelabelt werden dürfen.
Und zwar gilt hier die Norm:

QM
13485:2003

Richtlinie 93/42 EWG

Software:
IEC 60601-1-4
Basisnorm:
IEC 60601-1
EMV:
IEC 60601-2
etc.

Die Programmiersprache ist nicht vorgeschrieben, wir nutzen C.
Ebenso muß für alles eine Risikoanalyse gemacht werden.


Gruß

JN75

"fast alles noch mit Pascal oder BASIC gemacht wird"

Den Eindruck habe ich eigenlich weniger zumal Basic IMHO nicht zu den
sicheren und durchschaubaren Programmiersprachen zähl. Wenn schon, dann
wird das dannder Fall sein, wenn irgendwo noch Maschinen mit alten
Controller oder Platinen unterwegs sind.

Ich habe sowohl in C (Controller) als auch in C++ (Win-App)
programmiert und auch die mir bekannten alteren Systeme einiger großer
Anbieter aus den fühen 90ern laufen überwiegend mit Assembler oder C -
die moderneren, mit grafischen Eingabefunktionen versehenen Systeme
hingegen z.T. mit Echtzeitbetriebssystemen wie QNX + Photon.

Allesamt arbeiten mit uCs oder uC-basierten Hardwarestrukturen, oder in
jüngster Zeit mit in FPGAs gegossenen Softwarearchitekturen. Auch wenn
also die zur Verwendung angedachten uCs nicht ausdrücklich für
medizintechnische Anwendungen deklariert sind, so werden sie dennoch
eingesetzt. Eifriges Testes ist natürlich von Nöten.

Zu Deiner Frage ob ARM oder AVR: Das hängt von der Applikation ab. Ich
habe hier ein Beispiel einer ARM-basierten Kommunikationsplatform.
Diese ist für sich kein Medizingerät, wird aber zu einem solchen, wenn
es zum Transport wichtiger medizinisch relevanter Daten eingesetzt
wird.

http://home.arcor.de/devicemaster/applicationnote%20bmt.html

Solche Systeme müssen dann entsprechend sicher getestet bzw zuvor
sicher gemacht werden und genau aus dem Grund habe ich in diesem Falle
das hauseigene mitgelieferte Protokoll auf ECOS-Basis aufgebrochen und
mmit mehr Redundanz versehen. Hinzu kommt eine applikationsspezifische
Datenplausibilisierung.

@ JN75

Habt ihr ISO 9001/9002 oder schon das neue 16949 ( welches
Prozessgesteuert ist ) im Einsatz ?

mirki