Technische Informatik in der Biomedizin (TIBM) SS 2009

Vielzahl von Informationssystemen interagiert im klinischen Umfeld ƒ Standards erleichtern eine Kommunikation über Herstellergrenzen hinweg ƒ In dieser VL: ƒ DICOM – der Standard im radiologischen Umfeld ƒ “DICOM in Surgery” als Erweiterung von DICOM ƒ HL7 – Standard im KISUmfeld ƒ IHE als Verbindungsglied

Technische Informatik in der

Motivation & Überblick

Vielzahl von Informationssystemen interagiert im klinischen Umfeld

Standards erleichtern eine Kommunikation über

Herstellergrenzen hinweg

In dieser VL:

DICOM – der Standard im radiologischen Umfeld

“DICOM in Surgery” als Erweiterung von DICOM HL7 – Standard im KIS-Umfeld

IHE als Verbindungsglied

Standards - DICOM, IHE, HL7

3

Einführung

Informations- und Kommunikationstechnologie bei bildgestützten

Interventionen im heutigen modernen Operationssaal

Modularer Systemaufbau

Interventional Cockpit/SAS modules

IT Model-Centric World View Repo- sitory Engine ControlData Exch.

ling

Model-TIMMS ICT infrastructure (based on DICOM-X) for data, image,

model and tool communication for patient model-guided therapy

lation

Simu-Kernel for

WF and K+D Management

sation Rep Manager

Visuali- vention

Inter- ation

Comp.

tools

WF and K+D tools

Vali-Images

and

signals

Standards - DICOM, IHE, HL7

TIMMS & die reale Welt

Modellgestützte Therapie - Anforderungen

Modell des Patienten

Modell = Geeignete Abstraktion der Realität

Welche Abstraktion ist geeignet?

Wie wird diese Abstraktion gespeichert und präsentiert?

(z.B Nerv-Reizung, Puls, Anatomische Lagebeziehungen)

Kommunikation des Modells

Übertragung der benötigten Modellteile

Interaktion mit dem Modell

Dienste (Services)Präsentation

Für jede individuelle therapeutische Fragestellung lässt sich mit vorhandenen Methoden ein individuelles modellgestütztes Therapiesystem entwickeln!

(Voraussetzung: Modellierung muss möglich sein)

Problem:

Jede Systemkomponente muss immer neu integriert (und eventuell gekauft!) werden.

Systeme teuer Entwicklung aufwendig Viele Spezialisten notwendig

Neue, spezialisierte Anwendungen sind schwierig

Aspekte / Komponenten

TIMMS IuK - Netzwerke

Dedizierte Subnetze Echtzeit-

Bus

Definierte Latenzen Geringe Durchsatzraten

Video Dedizierte

Netze

Video-Ethernet

Netzwerk f

Gigabit-Datentransport

Streaming von Daten Biosignaldaten Navigationsdaten Video

Intraoperative Bilder

Funknetz Mobile

Datenerfassung

Flexible Systemkonfiguration

Lokalisation der Geräte?

Trennung von Datentransport und Kontrollflüssen

Punkt- Verbindungen

Punkt-zu- Topologie

Bus-Integration

in Kliniknetz HIS

RIS PACS

Computing

Grid-Lastverteilung Simulation

von Lastfällen NetzwerkstatusMonitoring des

Anbindung

Computing Teleconsulting

Grid-Teleradiologie Videorouting Telemonitoring

Netzwerkdiagnose Komponentenstatus

Telechirurgie Lehre / Präsentation

Hardwarekomponenten

Lokalisation

RFID Tracking

Interaktion Anzeigen

Zntraler Monitor Anzeige für

Chirurg

Anzeige für Anästhesie

OP-Dedizierte Gerätesteuerung OP-Bericht

Manipulationsassistenz

Automatisierungslevel Miniaturisierung

Sicherheit Zuverlässigkeit

Ausfallsicherheit

Redundanz Lastmessungen

Tests

Interoperabilität

Zerifizierung von Komponenten Zertifizierung

Schutz Manipulation

Bewusst

Unbewusst Zugriff auf Daten

Streams abhören EPR lesen Handlungsauthorisierung

Planung Diagnostik

Intelligenz / Workflow Workflowakquisition

Softwarekomponenten

Diagnose

CAD

Ferndiagnose Planung

Arbeitsraumplanung Zugangsplanung

Planungsalternativen / Simulation

Einbeziehung aller Modellparameter

Bildverarbeitung

Modelldatenverarbeitung

Musterpatienten Registrierung Segmentierung

Speicherung im

Workflowmanagement Ontologien

Patiendenmodell Andere Modelle Implantate Ergonomie

Assistenzsysteme

Steuerung

OP-OP-Setup Patientenvorbereitung Modellaktualisierung

Intraoperative Datenerfassung

Patientenmonitoring Klinik- Workflows

Lastausgleich

Standards - DICOM, IHE, HL7

TIMMS IuK - Netzwerke Dedizierte Subnetze Echtzeit- Bus

Navigationsdaten

Video

Intraoperative Bilder

Funknetz Mobile

Datenerfassung

Flexible Systemkonfiguration Lokalisation der Geräte?

Trennung von Datentransport und Kontrollflüssen Punkt-zu- Punkt- Verbindungen Bus- Topologie

Integration

in Kliniknetz HIS RIS PACS Grid- Computing

Lastverteilung Simulation von Lastfällen Monitoring des

Anbindung Grid- Computing Teleconsulting Teleradiologie

Videorouting Telemonitoring

Netzwerkdiagnose Komponentenstatus

Telechirurgie Lehre / Präsentation

Hardwarekomponenten Lokalisation RFID Tracking

Interaktion Anzeigen Zntraler Anzeige für Chirurg Anzeige für Anästhesie Eingabemöglichkeiten Touch Panel Sterilisierbar Spracherkennung OP- Saalsteuerung Dedizierte Gerätesteuerung OP-Bericht

Manipulationsassistenz

Automatisierungslevel Miniaturisierung

Sicherheit Zuverlässigkeit Ausfallsicherheit Redundanz Lastmessungen

Tests

Interoperabilität

Zerifizierung von Komponenten Zertifizierung

Schutz Manipulation Bewusst

Unbewusst Zugriff auf Daten

Streams

EPR lesen Handlungsauthorisierung Planung Diagnostik

Intelligenz / Workflow Workflowakquisition

Softwarekomponenten

Diagnose

CAD Ferndiagnose Planung

Arbeitsraumplanung Zugangsplanung

Planungsalternativen / Simulation Einbeziehung aller Modellparameter Bildverarbeitung

Modelldatenverarbeitung Musterpatienten Registrierung Segmentierung

Visualisierung von Modelldaten Speicherung im

Workflowmanagement Ontologien

Patiendenmodell Andere

Chirurgischer Workflow

Implantate Manipulatoren Ergonomie

Anatomie

Pathologie Radiologie

Modellparameter

Chirurgischer Workflow

Instrumente

Assistenzsysteme OP- Steuerung

OP-Setup Patientenvorbereitung Modellaktualisierung Intraoperative Datenerfassung

Patientenmonitoring Klinik- Workflows Lastausgleich

SDS-Gruppe TIMMS-Gruppe Workflow-Gruppe Patient-Modeling-Gruppe

Interoperabilität technischer Systeme wird auf lange Sicht immer über

Standards (ISO, DIN, ANSI, ieee, …) erreicht

Es existiert eine Palette an Standards, die zum Datenaustausch zwischen Systemen verwendet werden können:

OP-Klinische- bzw Medizinprodukte-StandardsStandardisierte Nomenklatur (SNOMED, LOINC, …)Standards aus anderen technischen Bereichen

(Computerwissenschaften, Telekommunikation, Maschinenbau, Elektrotechnik, Unterhaltungselektronik, …)

(De-Facto-Standards)

Regeln zur Nutzung von Standards

IHE (Integrating the Healthcare Enterprise)

Der im Rahmen des Projekts wichtigste Standard ist

„Digital Imaging and Communication in Medicine (DICOM)“

Standards - DICOM, IHE, HL7

IT in der Radiologie (RIS und PACS)

RIS: Radiologisches Informationssystem

Welcher Patient wird wann in welchem Raum mit welchen Methoden untersucht.

Protokollierung nach RöV (Geräteparameter, Strahlendosis, )

Befundschreibung

Schnittstelle zu Geräten (Parameter)

Zugriff auf klinische Daten und Vorbefunde

PACS: Picture Archiving and Communication System

„elektronischer Röntgenlichtrahmen“

Infrastruktur zur Bildkommunikation

inkl Patientendatenbank

Archivierung der Aufnahmen

Zugriff auf Voraufnahmen

Bildgebung im klinischen Workflow

Standards - DICOM, IHE, HL7

Etablierte Industriestandards

Health Level 7 (HL7)

Standard für elektronischen (textuellen) Datenaustausch im Gesundheitswesen

Digital Imaging and Communications in Medicine (DICOM)

Digital Imaging and Communications in Medicine (DICOM)

BilddatenübertragungBilddatenspeicherung (Datenformat)

Zunächst begegnet einem DICOM

meist als Dateiformat:

Header enthält MetadatenBody enthält Bilddaten

0002,0000,File Meta Elements Group Len=198 0002,0001,File Meta Info Version=256 0002,0002,Media Storage SOP Class UID=1.2.840.10008.5.1.4.1.1.2.

0002,0003,Media Storage SOP Inst

UID=1.2.840.113619.2.55.3.2126732283.5888.1175231464.730.11

[…]

0008,0008,Image Type=AXIAL […]

0008,0020,Study Date=20070330 0008,0021,Series Date=20070330 0008,0022,Acquisition Date=20070330 0008,0023,Image Date=20070330 0008,0030,Study Time=120230 0008,0031,Series Time=120425 […]

0008,0060,Modality=CT 0008,0070,Manufacturer=GE MEDICAL SYSTEMS 0008,0080,Institution Name=HELIOS.Krankenhaus.Leisnig 0008,0090,Referring Physician's Name=UNIHN

0008,1010,Station Name=CT99.OC0 0008,1030,Study Description=CT Hals 0008,103E,Series Description=3.5 Flow 100 ml […]

0010,0010,Patient's Name=Vorname.Nachname 0010,0020,Patient ID=0050074xxx

0010,0030,Patient Date of Birth=19991201 0010,0040,Patient Sex=F

Kommunikation über Wechseldatenträger (CD-ROM, ZIP, MOD, …)

Dateninhalte Funktionelle Anwendungen Hardwareübergreifend konsistente Anzeige von Bildern

Sicherheits- und Konfigurationsmanagement Arztbezogene Konfiguration der Benutzerschnittstelle (Hanging Protocol)

Identifikation und Gruppierung verwandter Informationen

(Structured Reports)

…

DICOM umfasst nicht

Implementierungsdetails Datenbankstrukturen Programmiersprachen Hardware

Betriebssysteme GUI-Design

…

Beispiele für DICOM-Nutzung

Standards - DICOM, IHE, HL7

DICOM-Aufbau

Umfang (Version 2007): 18 Dokumente, 3433 Seiten

PS 3.1: Introduction and Overview

PS 3.2: Conformance

PS 3.3: Information Object Definitions

PS 3.4: Service Class Specifications

PS 3.5: Data Structure and Encoding

PS 3.6: Data Dictionary

PS 3.7: Message Exchange

PS 3.8: Network Communication Support for Message Exchange

PS 3.9: Retired

PS 3.10: Media Storage and File Format for Data Interchange

PS 3.11: Media Storage Application Profiles

PS 3.12: Media Formats and Physical Media for Data Interchange

PS 3.13: Retired

PS 3.14 Grayscale Standard Display Function

PS 3.15: Security & System Management Profiles

PS 3.16: Content Mapping Resource

PS 3.17: Explanatory Information

PS 3.18: Web Access to DICOM Persistent Objects (WADO)

Permanente Aktualisierung durch Supplements und Correction Items

Message exchange

Network Communication for Message exchange

Part 14 Greyscale Standard Display Function

Part 15 Security and System Management Profiles

Part 16 Content Mapping Ressource

Part 17 Explan atory

Info Part 18

Web Access

Hitchhikers Guide to DICOM-Extensions

Die folgenden 5 Folien “Guide” entstammen einer ICCAS-internen

Präsentation von Michael Gessat zur Erweiterung von DICOM

Sie geben einen guten Überblick über die DICOM-Teile und den

Aufbau von DICOM und sind daher in diese Folien gewandert.

The Hitchhiker‘s Guide to DICOM

Part 1: Introduction & Overview: Tells you about what DICOM is, where it is coming from and something about the general architecture It also contains a brief overview of the content of each of the following parts

Don’t expect any changes here Just read it It helps!

Part 2: Conformance: DICOM is to some extent a meta-standard In the

conformance statement, the vendor of a DICOM conform device states how he implements DICOM and which parts of DICOM his device implements The

form and content of this conformance statement is specified in chapter 2

I didn’t see much change here in the supplements I read But maybe there will be a lot concerning the zero-conf stuff?

Part 4: Service Class Specifications: DICOM Objects can not be defined

without a Service Group applying to it and vice versa Part 4 specifies the

DIMSE (DICOM Message Service Element) Services and the Media Storage Services The Service Class Specifications describes the effect DICOM Services have on the IODs they apply to

As long as you only add new data-types to DICOM, you won’t have to change an lot here Maybe we’ll have to add new service types for streaming and for zero-conf

Guide #3

Part 5: Data Structures and Semantics: Tells you all about the dirty

bits-and-bites-details of encoding How many bits does an integer have? How long may

a string be? Look it up here!

Table 6.2-1 contains all available basic data types in DICOM That’s what you need! If you don’t plan to write your own parser or hand-code DICOM files, you won’t spend too much time with this one

Part 6: Data Dictionary: The Data Dictionary is the centralized registry for all Information Elements available in DICOM Nothing new here, basically a table containing all the attributes from Part 3 ordered by their tag-number and all UIDs given to concepts, SOPs,…

Once you’ve done your work in Parts 3 and 4, this is basically copy-paste

To be honest, I can’t foresee how our work will affect this part I just added

it since Parts 4 and 7 seem to have effects here We’ll possibly include some new protocols here

Part 15: Security and System Management Profiles: Specifies how DICOM uses several security-oriented standards in order to guarantee safe and secure

access and transfer to the Data

Whenever you add a module, you’ll have to insert it into the “what shall be considered” - tables Zero-conf might hugely affect this part

Guide #5

Part 16: Content Mapping Resource: Contains huge tables encoding words, concepts, names,… This part provides a kind of structured glossary and is the closest thing to an ontology in DICOM One of the fastest growing parts of

DICOM

When you include lists of anatomical structures, types of equipment, ways

to do something,… within a module, you put your list of possible entries here

Part 17: Explanatory Information: Whenever you feel, that the reader of your supplement might need a bit of assistance to understand it, like an example, put it here Nobody will admit, but this is what we all read when nobody

watches…

Especially in the discussion-phase: If in doubt, put it in!

Standards - DICOM, IHE, HL7

World Model

DICOM part 3, p 52

General Communications Model

Standards - DICOM, IHE, HL7

SOP-Klassen

DICOM definiert SOP-Klassen (Service-Object-Pair)

Service-Klassen gruppieren zusammengehörige

SOP-Klassen

Storage Service Class Print Management Service Class Study Management Service Class Das Verhalten der Service-Klassen ist klar definiert und die

Einhaltung wird im Conformance Statement beschrieben.

SCP / SCU

Service Class Provider (SCP):

• Application that is Providing the Service for a particular DICOM Function (SOP Class)

• Therefore, a device that can receive CT images over a network utilizing the DICOM protocol and stores those received CT images in its databases

would be called, in DICOM terms:

• that plays the network role of an SCP

• and follows the rules of the Storage Service Class.

• Service Class User (SCU):

• Application using a particular

DICOM Function (SOP Class)

Standards - DICOM, IHE, HL7

DICOM Part 2: Conformance Statement

Auszug/Quelle: Philips CT AV Series

DICOM Part 3: IODs

For each Information Objects Definition (IOD) this Part specifies:

any necessary information for the semantic description of the IODrelationships to associated real-world objects relevant to the IODAttributes which describe the characteristics of the IOD

For each IOD, this Part does not specify:

the nature of any Service Class Definition intended to reference the IODthe nature of any interactions which result in the usage of the IOD

Consists of

ER-Diagram

1002 pages…

Standards - DICOM, IHE, HL7

DICOM Part 3: IODs

Beispiel Waveforms

Mandatory, conditional, user option

DICOM Part 3: IODs

nested

Standards - DICOM, IHE, HL7

DICOM Part 4: Service Classes

For each Service Class Definition, this Part specifies:

the semantic description of the activities of the Service Class Definitionthe group of DICOM Message Service Element (DIMSE) Service operations and notifications applicable to the Service Class Description

one or more functionally-related Service-Object Pair (SOP) Classes which are supported by the Service Class Definition and may be performed between peer DICOM Application Entities

the relationship of each Service-Object Pair (SOP) Classes to applicable Information Object Definitions specified in PS 3.3

For each Service Class Definition, this Part does not specify:

any necessary information for the semantic description of the IODrelationships to associated real-world objects relevant to the IODattributes which describe the characteristics of the IOD

DICOM Part 4: Service Classes

Standards - DICOM, IHE, HL7

Part 5:

Part 5

Enhancing DICOM towards Surgery

“DICOM for Surgery”

Archivierung, Übertragung und

Speicherung digitaler

radiologischer Patientenbilder

In der Radiologie etabliert.

CAS-Anwendungen sind i.d.R

bildzentrisch

Zusätzliche Datenstrukturen, nicht

in DICOM

Eine internationale Arbeitsgruppe

(DICOM Working Group 24)

wurde eingerichtet, um DICOM

für die Chirurgie zu erweitern.

Standards - DICOM, IHE, HL7

TIMMS & die reale Welt

Analyse von chirurgischen Prozessen zur Use Case Definition