Picture Archiving and Communication System

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
PACS-Server (ganz unten) aus dem Jahr 2011 mit 40 Terabyte RAID-Archiv. Das Kurzzeitarchiv ist über dem Server angeordnet, darüber befindet sich das Langzeitarchiv. Ganz oben: zwei Switche mit Lichtleitern (orange) für den Heartbeat, mit dem der Spiegelserver verbunden ist.

Ein Picture Archiving and Communication System (PACS, etwa Bildablage- und Kommunikationssystem) ist in der Medizin ein Bildarchivierungs- und Kommunikationssystem auf der Basis digitaler Rechner und Netzwerke. Die ersten PACS-Entwicklungen begannen in den 1970er Jahren. Signifikante Verbreitung in Krankenhäusern und Arztpraxen fand es jedoch erst in den späten 1990er Jahren.[1]

PACSe[2] erfassen digitale Bilddaten aller Modalitäten in der Radiologie und der Nuklearmedizin. Grundsätzlich kommen auch Bilder aus anderen bildgebenden Verfahren, etwa aus Endoskopie, Kardiologie, Pathologie und Mikrobiologie, für die PACS-Verarbeitung in Frage.

Einzelne Computeranlagen, die mit einem einzigen Diagnosegerät permanent verbunden sind und PACS-Aufgaben erfüllen, bezeichnet man als Mini-PACS.

Beschreibung[Bearbeiten | Quelltext bearbeiten]

Ein PACS besteht aus dem PACS-Server, an den ein Kurzzeit- und ein Langzeitarchiv angeschlossen ist. Der PACS-Server sendet an Betrachtungs- und Nachverarbeitungsrechner, kommuniziert aber auch mit den angeschlossenen bildgebenden Modalitäten. In den meisten Fällen findet darüber hinaus auch eine Anbindung an das Radiologie-Informationssystem (RIS) statt. Größere PACS-Installationen können auch aus mehreren u. U. über weite Strecken gekoppelten Servern und Archiven bestehen.

Um die Integration der verschiedenen Komponenten miteinander und die Einbettung von PACS in Krankenhausinformationssysteme zu ermöglichen, sind die Standards DICOM und HL7 von internationalen Konsortien entwickelt worden. Die IHE (Integrating the Healthcare Enterprise) ist eine Organisation, die verschiedene Standards zu sogenannten Anwendungsprofilen zusammenfasst. Ein PACS kann dann einem oder mehreren dieser Profile entsprechen.

DICOM[Bearbeiten | Quelltext bearbeiten]

Zusammen mit den Bilddaten werden mit jedem Bild auch Metadaten gespeichert. Gezeigt ist eine Auswahl der in einer Datenbank des PACS abgelegten Metadaten.

Wichtigste Voraussetzung für die Etablierung von PACSen war der DICOM-Standard,[1] denn durch eine einheitliche DICOM-Kommunikation lassen sich PACS-Server und bildgebende Geräte herstellerunabhängig einsetzen und die Anbindung eines Gerätes wird einfach und kostengünstig. Moderne Großgeräte der medizinischen Bildgebung wie CTs, PET/CTs, MRs oder SPECT-Kameras liefern Bilddaten durchwegs in digitaler Form gemäß dem DICOM-3-Standard. Ähnlich wie beim Exchangeable Image File Format besteht ein Bild bzw. eine Bildserie hier aus zwei Teilen: Neben dem eigentlichen Bild wird im sogenannten DICOM-Header eine Fülle von Informationen abgelegt.[3] Es sind dies u. a. die Identität des Patienten, Untersuchungsdatum und Uhrzeit, klinische Fragestellung, Art, Typ und Hersteller des verwendeten Gerätes, aber auch Name und Adresse der untersuchenden Institution. Wenn als Filmaufnahmen vorliegende Bilder erfasst werden müssen, werden diese mit Hilfe eines Scanners digitalisiert, der die Informationen für den DICOM-Header vom RIS erhält. Anschließend wird das Bild zum PACS transferiert.

Insbesondere bei älteren Geräten wurde der Standard bisweilen leider nicht eingehalten oder es wurden nicht alle Felder mit Informationen gefüllt, was zu Kommunikations- bzw. Speicherfehlern führte. Oft wird die Möglichkeit, die Bilddaten im DICOM-Standard zu speichern, vom Gerätehersteller auch nur optional (überteuert) angeboten. Bis heute (Stand 2011) gibt es bildgebende Geräte wie z. B. (OP-)Mikroskope oder Endoskopie-Geräte, die ihre Bilddaten nicht im DICOM-Standard zur Verfügung stellen. In diesem Fall kann die Bildinformation über Framegrabber-Karten erfasst und mit Hilfe von speziellen Softwareprodukten in das DICOM-Format konvertiert werden.

Die Funktionalität, Nicht-DICOM-Bilder ins DICOM-Format zu konvertieren oder diese ohne Konvertierung zu speichern, wird jedoch zunehmend auch von PACS-Herstellern angeboten und im Archivspeicher abgebildet.

Server und Speicher[Bearbeiten | Quelltext bearbeiten]

Kern eines jeden PACS ist der PACS-Server. Alle Modalitäten einer PACS-Umgebung liefern ihre Bilder hier ab und hier werden sie auch gespeichert. In praktisch jedem heutigen Krankenhaus der Industriestaaten werden sämtliche Bilddaten der Radiologie im PACS gespeichert. In einem typischen 400-Betten-Krankenhaus beträgt diese Datenmenge pro Jahr ca. drei bis fünf Terabyte. Das Radiologie-Archiv eines Universitätsklinikums kann folglich mehrere 100 Terabyte groß sein. Die genaue Größe und Menge der anfallenden Bilder schwankt jedoch in Abhängigkeit von der Art und Zahl der angeschlossenen Modalitäten. So produziert ein moderner 64-Zeilen-CT ein Mehrfaches der Bilder, die ein älterer 4-Zeilen-CT ausgibt. Die Datenmenge eines Mammographiebildes ist auch erheblich größer als die einer konventionellen Röntgenaufnahme.

Im Speicher des PACS-Archivs liegen die Bilddaten bisweilen nicht mehr in der DICOM-Datenstruktur vor. Bei manchen Systemen nimmt der PACS-Server die DICOM-Daten entgegen, trennt Header und Bilddaten und speichert beide Informationen – bisweilen komprimiert – in einer gängigen Datenbank ab. Es werden dort neben den Informationen des DICOM-Headers auch weitergehende Informationen, wie Änderungen oder Verschiebungen des Bildes abgelegt. Werden die Bilder von einer Gegenstelle abgerufen, werden sie für den Versand wieder in das DICOM-Format rückkonvertiert.

Datensicherheit[Bearbeiten | Quelltext bearbeiten]

Da der PACS-Server die Bilddaten für die gesamte Institution zur Verfügung stellt, bedeutet sein Ausfall, dass keine Bilder archiviert und – außer die aktuellen Bilder am bildgebenden Gerät selbst – auch nicht betrachtet werden können. Somit muss das PACS nicht nur mit einer hohen Speicherkapazität, sondern auch mit hoher Ausfallsicherheit konzipiert sein. Der Gesetzgeber gibt vor, dass Röntgenaufnahmen mindestens 10 Jahre aufzubewahren sind, bei unter 18-Jährigen bis zur Vollendung des 28. Lebensjahres des Patienten.[4]

Meist wird das Bildarchiv in einen Kurzzeit- und einen Langzeitspeicher unterteilt. Im Langzeitspeicher sind Bilder zu finden, die älter als die vom Administrator des Systems festgelegte Zeit – typischerweise ein halbes bis zwei Jahre – sind. Auf diese Weise kann der Langzeitspeicher kostengünstiger als der Kurzzeitspeicher implementiert werden. Der Kurzzeitspeicher wird so ausgelegt, dass sehr schnell auf diese häufig abgerufenen Bilddaten zugegriffen werden kann. In älteren PACSen wurden für den Langzeitspeicher bisweilen sehr langsame Bandlaufwerke oder auch CD-Jukeboxen eingesetzt. Im Jahr 2012 wurden aber in den meisten Fällen für die Kurzzeitspeicherung und für die Langzeitarchivierung RAID-Archive benutzt. Das Langzeitarchiv wird beispielsweise als RAID 61 ausgelegt, während das Kurzzeitarchiv oftmals ein RAID 51 ist.

2011 waren über zwei räumlich getrennte Standorte gespiegelte und via Hochgeschwindigkeits-Glasfaser-Verbindung (> ca. 4 GBit/s) gekoppelte RAID-Systeme und HA-Cluster üblich. Jeder einzelne Spiegel besteht aus einem allein voll funktionsfähigen PACS, ist aber selbst auch redundant konzipiert. So wird bei Ausfall einer Festplatte eine sofort verfügbare Reserveplatte aktiviert, die sogenannte Hot-Spare. Netzwerkkomponenten wie z. B. Switche oder Glasfaserleitungen sind doppelt vorhanden. Ist der Fehler so schwerwiegend, dass das System nicht mehr funktionsfähig ist, wird unterbrechungsfrei der Spiegelserver aktiviert.

Server und RAID-Controller verfügen über zwei bis drei Netzteile, so dass das System auch beim Ausfall eines Netzteils oder eines Stromkreises weiterläuft. Idealerweise werden sowohl die redundanten Komponenten eines Servers wie auch der Spiegelserver von getrennt abgesicherten Stromkreisen versorgt und sind an eine unterbrechungsfreie Stromversorgung angeschlossen.

Im System auflaufende Fehler lösen vollautomatisch E-Mails an die Administratoren des Systems aus, die damit ohne Zeitverzögerung geeignete Maßnahmen zur Fehlerkorrektur einleiten können. Trotz dieser Sicherheitsvorkehrungen werden die Bilddaten üblicherweise zusätzlich auf Bandlaufwerken gesichert, so dass im sehr unwahrscheinlichen Totalausfall des Speichersystems noch Backups der Bilder vorhanden sind.

Bei RAIDs, in denen die Festplatten deutlich über die vom Hersteller für die Berechnung der MTBF zugrundegelegte Zeit von zwei bis drei Jahren betrieben werden, besteht trotz der beschriebenen Mechanismen die Möglichkeit, die Daten eines RAID zu verlieren. Auf Bilddaten, die älter als ca. zwei Jahre sind, wird nur sehr selten zugegriffen. Dies führt dazu, dass die Plattenbelastung des Langzeitarchivs in der Regel sehr gering ist. Die Platten des RAID könnten daher altern bzw. verschleißen, ohne dass sich dies in einem Ausfall einer Platte zeigt. Dadurch entsteht der falsche Eindruck, die Platten des RAID wären in Ordnung, obwohl sie es möglicherweise gar nicht mehr sind. Wenn dann doch eine Platte ausfällt, wird vom RAID-Controller mit Hilfe der Hot-Spare mit dem Wiederaufbau der auf der ausgefallenen Platte abgelegten Daten begonnen. Der Wiederaufbau dieser Daten einer defekten Platte bedeutet für die verbliebenen Platten jedoch eine sehr starke Belastung; somit kann die durch den Aufbau ausgelöste Belastung der verbliebenen funktionierenden Platten zu einem Ausfall einer weiteren Platte führen, bevor der Wiederaufbau beendet ist. Da in solch einem Fall die Daten eines RAID 5 verloren wären, werden Langzeitarchive in der Regel als RAID 6 ausgeführt. Ein RAID 6 kann auch den gleichzeitigen Ausfall zweier Festplatten verkraften. Der Wiederaufbau von Daten defekter Platten kann durchaus 10 Stunden und mehr dauern. Bei Verwendung eines RAID 6 ist das Risiko eines totalen Datenverlusts im beschriebenen Szenario zwar gering, jedoch nicht vollständig zu vernachlässigen. Dies ist ein Grund, weshalb es sinnvoll ist, die Platten des RAID des Langzeitarchivs rechtzeitig zu tauschen, auch wenn sie nicht defekt sind, sowie das Langzeitarchiv in Form zweier räumlich getrennter RAID 6 zu implementieren.

Arbeitsplatzrechner zur Bildbetrachtung und Nachverarbeitung[Bearbeiten | Quelltext bearbeiten]

An speziellen Arbeitsplatzrechnern werden die Untersuchungen abgerufen. Während die Kommunikation zwischen dem PACS-Archiv und dem Medizingerät dem DICOM-Standard folgt, werden Daten zwischen dem Arbeitsplatzrechner und dem Archiv bisweilen in proprietären Formaten übertragen. Der Grund dafür ist, dass eine Netzwerk-Kommunikation via DICOM query/retrieve bzw. store nicht sehr effektiv ist, d. h., es werden hierbei viele Informationen mitübertragen, die teils redundant und/oder für die Bilddarstellung nicht relevant sind. Ebenso werden bei einer Übertragung gemäß DICOM 3 Bilder einer Serie der Reihe nach übertragen, während bei einer Übertragung via z. B. HTTP ein beliebiges Bild einer Serie vorrangig übertragen werden kann, was die Ladezeit verkürzt. Daher ist die Software der Arbeitsplatzrechner und die des Archivs im Allgemeinen vom selben Hersteller. Für eine HTTP-basierte Übertragung gemäß DICOM-Standard gibt es seit wenigen Jahren den WADO-Standard.

Bilder werden, wenn nötig, bei der Darstellung digital nachbearbeitet: Meist wird die Zuordnung gemessener Werte (Röntgenabsorption, Signalintensität etc.) zu Grauwerten manipuliert (Fensterung) oder nachträgliche Strukturmessungen durchgeführt. Nach der Begutachtung der Bilder im Licht der Krankengeschichte erstellt der Radiologe einen schriftlichen Befundbericht. Dazu ist am PACS-Arbeitsplatzrechner üblicherweise auch ein RIS-Client und eine Spracherkennungssoftware installiert.

An weniger aufwendig ausgestatteten Arbeitsplatzrechnern im Stations- und Poliklinikbereich können Bilder und Befundbericht ebenso eingesehen werden. Dazu eignet sich in der Regel ein herkömmlicher PC; die Bildbetrachtung findet dann entweder mit Hilfe einer kleinen Spezialanwendung oder im Webbrowser statt.

Vernetzung mit anderen IT-Systemen[Bearbeiten | Quelltext bearbeiten]

Schon bei den ersten PACSen war angedacht, diese eng mit anderen IT-Systemen zu vernetzen,[1] was aber in Ermangelung relevanter Kommunikationsstandards anfangs nur in begrenztem Umfang gelang. Durch die stete Weiterentwicklung von DICOM und HL7 war es aber schon im Jahr 2010 meist sehr gut möglich, KIS, RIS und PACS eng zu verzahnen.

Beispiel: Eine radiologische Anforderung, die ein Mitarbeiter im KIS anmeldet, wird an das RIS weitergereicht, die Untersuchungsdaten mit den PACS-Studien verknüpft. Damit ist es möglich, dass der im RIS gespeicherte radiologische Befund zusammen mit den PACS-Bildern im KIS und somit im gesamten Krankenhaus abrufbar sind. Die enge RIS-PACS-Verzahnung ermöglicht auch den Aufruf von PACS-Bilddaten von KIS und RIS aus. Der Arzt wählt nur Patient und ggf. die Untersuchung an, das PACS zeigt unmittelbar die dazugehörigen Bilddaten. Auch Fehlerkorrekturen werden durch die enge Verzahnung der Systeme vereinfacht. Wird der Name des Patienten bei der Anmeldung im KIS versehentlich falsch geschrieben, so löst eine Korrektur der Patientendaten im KIS eine HL-7-Nachricht aus, die sowohl an das RIS als auch an das PACS weitergereicht wird. Eine Namenskorrektur „Maier zu Mayer“ muss damit nur einmal im KIS erfolgen, RIS und PACS werden automatisch synchronisiert.

Tendenzen der Weiterentwicklung[Bearbeiten | Quelltext bearbeiten]

Im Bereich PACS gab es seit dem Beginn des 21. Jahrhunderts eine Reihe von Entwicklungstendenzen.[5]

Deconstructed PACS[Bearbeiten | Quelltext bearbeiten]

Während viele PACS als tief verzahnte Lösungen mit proprietären Schnittstellen realisiert sind, wird von Anwendern und Fachleuten die Zerlegung in die drei Bestandteile Workflow (RIS), Archiv und Viewer als vorteilhaft betrachtet.[6][7] So stellen sich die Betreiber das ideale PACS/RIS nach der Best-of-Breed-Strategie zusammen und verknüpfen die Komponenten mit Standardschnittstellen (DICOM, HL7, IHE). Da man bei diesen Implementierungen flexibel in der Auswahl der einzelnen Anbietern ist, spricht man in diesem Zusammenhang auch von einem 'vendor neutral Archive' bzw. einem 'vendor neutral PACS'.

Virtualisierung[Bearbeiten | Quelltext bearbeiten]

Um einen PACS-Server in den 1990er Jahren so zu implementieren, dass der Anwender eine zufriedenstellende Performance verfügbar hatte, war hochpreisige Server-Hardware nötig. Das PACS-Archiv war hierbei die einzige laufende Anwendung, denn es gab keine ausreichenden Ressourcen, auf dieser Hardware weitere Server laufen zu lassen. Etwa ab den 2010er Jahren wurde Server-Hardware so günstig und so leistungsfähig, dass man PACS-Server dann virtualisieren konnte. Dies brachte dem PACS alle Vorteile, die eine Virtualisierungen hat, wie einfache Wartbarkeit und Ausfallsicherheit.[5]

Integration von Nicht-Dicom-Objekten[Bearbeiten | Quelltext bearbeiten]

Es gibt eine Reihe von PACS-Systemen, die nicht nur DICOM-Objekte, sondern auch Nicht-Dicom-Objekte speichern und verwalten können.[5] In diesen Archiven werden dann beispielsweise auch Befunddokumente oder Biosignale abgelegt und können über denselben Viewer betrachtet werden, der für die Darstellung von DICOM-Objekten benutzt wird.

Cloud-Speicher[Bearbeiten | Quelltext bearbeiten]

Einige PACS-Hersteller führen ihre Langzeit-Bildspeicherung in der Cloud durch und können so die Kosten senken und eine standortübergreifende Verfügbarkeit verbessern. Während für die Befundung aktueller Bildgebung meist nur Voraufnahmen der letzten zwei bis drei Jahre relevant sind, schreibt der Gesetzgeber vor, dass Radiologische Bilddaten mindestens 10 Jahre gespeichert werden müssen. Daher kann ein PACS so auslegen, dass die Bildgebung der letzten paar Jahre vor Ort vorgehalten wird, wohingegen man ältere Daten problemlos auch in langsameren Cloud-Speicher auslagern kann, denn darauf wird nur selten zugegriffen.[5]

Standortübergreifende Vernetzung[Bearbeiten | Quelltext bearbeiten]

Bei größeren Installationen ist es wichtig, auch Funktionalitäten bereitzustellen, die eine standortübergreifende Nutzung der Systeme ermöglichen. Verwandt damit ist die Einbindung in ein Teleradiologie-Netzwerk, in dem mehrere Krankenhäuser oder Gesundheitseinrichtungen, Daten austauschen können.[5]

PACS as a Service[Bearbeiten | Quelltext bearbeiten]

Einige Anbieter verkaufen nicht die Software-Lizenzen, sondern die Dienstleitung. Der Kunde kauft also weder Hard- noch Software, sondern bezahlt den Anbieter auf Basis der gespeicherten Datenmenge.[5]

Anbindung von Dritt-Systemen[Bearbeiten | Quelltext bearbeiten]

Viele PACS-Systeme bieten die Möglichkeit, Fremdsysteme einfach aus dem PACS heraus aufrufen zu können. Hier sind Systeme für die erweitere Bildauswertung, KI-Systeme oder Planungssysteme für die Endoprothetik zu nennen.[5]

Cybersicherheit[Bearbeiten | Quelltext bearbeiten]

In den Anfangsjahren war man PACS-seitig darauf fokussiert, eine Datenkompatibilität zwischen den kommunizierenden Systemen zu ermöglichen und eine zuverlässige Speicherung sicherzustellen. In den letzten Jahren gelangte aber auch die Absicherung vor Cyberangriffen zunehmend in den Fokus der Entwickler; so kann man heute zwischen Modalität und PACS auch eine zertifikatbasierte, verschlüsselte Kommunikation realisieren.[5] Das Bundesamt für Sicherheit in der Informationstechnik hatte 2013 einen Leitfaden herausgegeben, in dem Empfehlungen für die Verbesserung der Sicherheit im Krankenhausumfeld beschrieben sind. Dort wird beispielsweise empfohlen, die Netzwerke über die Medizingeräte mit dem PACS kommunizieren, vom übrigen Krankenhausnetzwerk zu trennen.[8]

Vor- und Nachteile[Bearbeiten | Quelltext bearbeiten]

Vorteile[Bearbeiten | Quelltext bearbeiten]

Im Unterschied zur Bilddokumentation auf Papier- oder Filmträgern arbeiten PACSe mit digitalen Bilddaten. Dadurch ergeben sich umfassende Möglichkeiten zur Erhöhung der Funktionalität und Effizienz von Arbeitsabläufen.

Durch die digitale Speicherung bleibt die Qualität der Aufnahmen auch über viele Jahre unverändert. Bei projektionsradiografischen Verfahren ermöglicht die digitale Erfassung einen höheren Kontrastumfang. Aufnahmen sind somit informativer, Wiederholungsaufnahmen nach Fehlexpositionen seltener als bei der Filmradiografie.

Für Schnittbildverfahren ergeben sich erweiterte Möglichkeiten für Betrachtung und Befundung. So kann eine Schnittserie als Animation dargestellt oder jederzeit auch in eine MPR bzw. in ein 3D-Modell umgerechnet oder mit spezieller Auswertesoftware nachbearbeitet werden. PACS vereinfacht auch die Dokumentation von Bewegtaufnahmen beim Ultraschall.

Ein wesentlicher Vorteil ist die gleichzeitige Verfügbarkeit von Bildern an mehreren Orten (auch innerhalb eines Krankenhauses) über ein Rechnernetz, was den logistischen Aufwand für den konventionellen Bildtransport komplett entfallen lässt. Da die Bilder auch über größere Distanzen reproduziert werden können, kann die Begutachtung zeitlich und räumlich flexibler gestaltet werden (siehe auch Teleradiologie). Aufnahmen können verlustfrei kopiert werden. Umständliche Filmarchivierung entfällt. Das Risiko des Verlustes einzigartiger Originalaufnahmen wird minimiert.

Einsparungen an Bildmedien, Transportkosten und Archivierungsplatz sind weitere, wesentliche Vorteile.

Nachteile[Bearbeiten | Quelltext bearbeiten]

In den ersten Jahren der PACS-Einführung krankten PACS-Umgebungen häufig an mangelhaften DICOM-Implementierungen, so dass scheinbar DICOM-kompatible Geräte vielfach nicht angebunden werden konnten oder Daten nur eingeschränkt speicher- bzw. lesbar waren. Ebenso waren die Rechner- und Netzwerkarchitekturen der ersten PACS-Server und Workstations der Größe der Bilddatenmenge nicht gewachsen, was zu übermäßig langen Transfer- und Ladezeiten führte. Ein hoher Wartungsaufwand, hohe Systempreise und bisweilen geringe Zuverlässigkeit führten dazu, dass PACSe und das PACS-Konzept oftmals stark in der Kritik standen und der Nutzen von PACS hinterfragt wurde.

Trotz großem hardwareseitigen Aufwand und redundanten Servern ist es möglich, dass auf das PACS nicht zugegriffen werden kann. Ursachen können sein: physische Unterbrechung von Netzverbindungen, Ausfall von Switchen, Fehlkonfiguration von beispielsweise neu ins Netz aufgenommenen Geräten oder der Absturz von Server-Diensten. Eine derartige Unterbrechung betrifft meist mehrere, im schlimmsten Fall alle Nutzer des PACS. Wie bei anderen zentralen, Server-basierten IT-Systemen ist der resultierende Produktivitätsausfall daher meist hoch.

Geschichte[Bearbeiten | Quelltext bearbeiten]

Obgleich medizinische Bilddaten bereits in den 1970er Jahren digital gespeichert werden konnten, blieben Versuche, digitale Archive zu etablieren, in Ermangelung standardisierter Datenformate proprietäre Insellösungen. Erst die im Jahr 1983 begonnene Entwicklung des DICOM-Standards ermöglichte auch eine herstellerübergreifende PACS-Entwicklung. Da die ersten Geräte, die ihre Daten im DICOM-Format ausgeben konnten, mit der Verabschiedung des bis heute gültigen DICOM 3.0 erst von 1993 an auf den Markt kamen, waren PACSe auch gegen Ende des 20. Jahrhunderts kaum in Krankenhäusern anzutreffen. Noch im Jahr 2005 besaßen lediglich geschätzte 22 % aller nordamerikanischen Krankenhäuser ein PACS.

Bei Verabschiedung des DICOM-Standards im Jahr 1993 betrug die Datentransferrate von Ethernet 10 MBit/s. Selbst hochpreisige Workstations hatten wenige Dutzend Megabyte RAM und nur einige hundert Megabyte fassende Festplatten. 2011 lag die gängige Transferrate von Ethernet bei 1 GBit/s: Ein preiswerter PC „von der Stange“ verfügte über mehrere Gigabyte RAM, hunderte Gigabyte fassende Festplatten und eine um mehrere Größenordnungen höhere Rechenleistung als Rechner aus den 1990er Jahren. Die Bilddatenmenge in der Radiologie ist im Verlauf der ca. zwanzig Jahre PACS-Entwicklung zwar auch gestiegen, jedoch bei weitem nicht in dem Maße, in der die Leistungsfähigkeit von Rechnern und Netzinfrastrukturen zunahm. Eine Thorax-Röntgenaufnahme ist heute genauso groß wie vor 20 Jahren. In Kombination mit dem andauernden Preisverfall von IT-Systemen sowie weiterentwickelter wie auch besser eingehaltener Kommunikationsstandards führte dies zu einer sehr starken Verbreitung von PACS. Der Nutzen von PACS überwog 2011 (scheinbar) klar den damit verbundenen Aufwand.[1]

Im Jahr 2016 veröffentlichte Oleg Pianykh, Professor für Radiologie an der Harvard Medical School, eine Studie zu ungeschützten PACS-Servern. Er hatte damals mehr als 2700 offene Systeme ausfindig machen können. 2019 stehen in 52 Ländern der Welt ungeschützte Systeme mit über 24 Millionen Datensätzen und mehr als 700 Millionen verlinkten Bildern. Aus diesen sind 400 Millionen tatsächlich herunterladbar.[9]

Klassifizierung als Medizinprodukt[Bearbeiten | Quelltext bearbeiten]

PACS-Software (z. B. bei der Archivierung und Befundung von Bilddaten) wird in der gesamten Europäischen Union in der Regel als Medizinprodukt der Klasse IIa in Verkehr gebracht. Falls die PACS-Software Einfluss auf die Wirkungsweise eines mit ihr verbundenen Medizinproduktes hat (z. B. bei Funktionalitäten zur Strahlentherapieplanung), kann sie der Klasse IIb zugeordnet werden. Das Konformitätsbewertungsverfahren unterliegt der Überwachung durch eine sogenannte Benannte Stelle. Medizinprodukte wie PACS bestehen ggf. aus mehreren Komponenten, die einzeln bewertet werden können. Diese Komponenten können daher auch, in Abhängigkeit ihrer jeweiligen Zweckbestimmung, unterschiedliche Klassifizierungen aufweisen.

Literatur[Bearbeiten | Quelltext bearbeiten]

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. a b c d The Prophet Motive: How PACS was developed and sold (Memento des Originals vom 5. Oktober 2011 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.imagingeconomics.com Imageeconomics.com
  2. Aus dem englischen Akronym ist im deutschen Gebrauch ein eigenständiges Lehnwort entstanden. In diesem Artikel wird daher PACS als Nomen mit großem Anfangsbuchstaben verwendet.
  3. Center for Advanced Brain Imaging (CABI). Abgerufen am 29. Oktober 2023 (amerikanisches Englisch).
  4. § 85 StrlSchG - Einzelnorm. Abgerufen am 23. November 2023.
  5. a b c d e f g h 5 Major Trends Shaping the Future of Enterprise Imaging. 9. März 2023, abgerufen am 7. Februar 2024 (englisch).
  6. Jim Philbin, PhD: Guest column: The impending deconstruction of PACS. In: Health Imaging. Innovate Healthcare, 5. Juni 2012, abgerufen am 29. Oktober 2023 (englisch).
  7. Deconstructed PACS. (Memento des Originals vom 12. Februar 2015 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/pacsmonkey.blogspot.de PACS Administrator Blog
  8. publisher: Risikoanalyse Krankenhaus-IT (Langfassung). Abgerufen am 7. Februar 2024.
  9. Unsicher konfigurierte Server leaken Daten von Millionen Patienten. heise.de, 19. September 2019