IHE Integrationsprofile

IHE-Integrationsprofile

Diese Seite soll einen Überblick verschaffen, in welcher Systemkonstellation welche Akteure eines IHE-Integrationsprofils relevant oder auch nur optional sind. Nachfolgend sind für die primären Kommunikationsszenarien die entsprechenden Details aufgelistet:

Legende:

• R = Required (muss vorhanden sein)
• RE = Required but may be empty (sollte unterstützt sein)
• O = optional (kann implementiert werden)
• X = not permitted (nicht erlaubt)

besser:

• verpl. (verpflichtend)
• empf. (empfohlen)
• opt. (optional)
• nicht empf. (nicht empfohlen)

Einsatz existierender Integrationsprofile

Nachfolgend werden die Integrationsprofile aus den jeweiligen Domänen vorgestellt. An dieser Stelle sei noch einmal auf das IHE_DE_Cookbook IHE-Cookbook verwiesen, in dem einige Profile noch einmal genauer beschrieben sind. Es ist auch zu beachten, dass zur Lösung konkreter Probleme mitunter mehrere Profile miteinander kombiniert werden müssen, d.h. ein System muss die Rollen mehrerer Akteure gleichzeitig übernehmen.

Nachfolgend werden die Akteure der verschiedenen Integrationsprofile gemäß ihres Einsatzzweckes und im Hinblick auf eine sinnvolle Gruppierung vorgestellt.

Radiologie

Kommunikation KIS-RIS-PACS

Profil	Erklärung / Akteur	KIS	RIS	PACS	Gerät	Kommentar
PAM	Austausch administrativer Basisdaten (Person + Fall)					Dieses Profil ist bei ITI beschrieben.
	Pat. Demographics Supplier	verpfl.	opt.	X	X
	Pat. Demographics Consumer	opt.	verpfl.	R	R
	Pat. Encounter Supplier	verpfl.	O	X	X
	Pat. Encounter Consumer	opt.	R	R	R
RID	Abfrage von Informationen zur Anzeige
	-					Nicht empfehlenswert, da die unterstützten Dokumente sehr limitiert sind. Stattdessen besser XDS nutzen.
PDI	Ablage von radiologischen Befunden und Bilder auf beweglichen Datenträgern
	???
PIR	Korrektur von Patienten Informationen
	Order Placer	R	O	X	X
	ADT	R	O	X	X
	DSS/Order Filler	X	R	X	X
	Performed Procedure Step Manager	X	O	O	X
	Report Manager	X	RE	O	X
	Report Creator	X	RE	O	X
	Image Archive/Image Manager	X	X	R	X
	Acquisition Modality	X	X	X	R
SWF	Basis Workflow in der Radiologie
	Order Placer	R	O	X	X
	ADT	R	O	X	X
	DSS/Order Filler	X	R	X	X
	Performed Procedure Step Manager	X	R	R	X	einer von beiden
	Evidence Creator	X	O	R	X
	Image Archive/Image Manager	X	X	R	X
	Acquisition Modality	X	X	X	R
RWF	Befunderstellungs-Workflow
	-					In DE überflüssig, da Befunde üblicherweise im RIS und nicht im PACS erstellt werden
IRWF	Workflow zum Import von Fremdbildern von beweglichen Datenträgern
		X	O	R	X
NMI	Beschreibung für Bilder aus der Nuklearmedizin
	-					Nur für Nuklearmedizin notwendig, nicht für Radiologie
MAMMO	Beschreibung für Bilder aus der Mammographie
		X	X	O	O
ED	Beschreibung von Dokumenten mit aus den Bildern bestimmten Fakten (z.B. Messwerte)
		X	O	O	X
SINR	Beschreibung von Radiologischen Befunden als DICOM SR Objekten
	-					Nicht empfehlenswert, da DICOM SR nur von wenigen Systemen verstanden werden. Besser sind CDA Dokumente.
CT	Abgleich der systeminternen Uhren
	Time Client	R	R	R	R
REM	Austausch von Dosisinformationen
	Image Archive/Image Manager	X	X	R	X
	Dose Info Consumer	O	O	X	X
	Acquisition Modality	X	X	X	R
CHG	Charge Posting: Leistungserfassung
	Charge Processor	O	X	X	X	typischerweise KIS, kann aber auch spez. Subsystem sein
	Order Filler	O	RE	X	X	jedes leistungserbringende System

Bildverarbeitung

Die hier vorgestellten Profile dienen primär der Anzeige und Bearbeitung der Bilder.

Profil	Erklärung / Akteur	KIS	RIS	PACS	Gerät	Kommentar
KIN	Key Image Note: Markieren relevanter Bilder
	???
CPI	Consistent Presentation of Images: einheitliche Bilddarstellung
	???
PGP	Presentation of Grouped Procedures: Zusammenfassen von Bildern
	???
FUS	Image Fusion
	???

Labor

Profil	Erklärung / Akteur	KIS	LIS	Analysegerät	Kommentar
LTW	Laboratory Testing Workflow				kombiniert mit PAM
	Order Placer	RE	O	X
	Order Filler	X	R	X
	Order Result Tracker	RE	X	X	typischerweise das KIS, aber andere interessierte Systeme
	Automation Manager	X	R	X
XD-LAB	Sharing Laboratory Reports
	Content Creator	O	R	X	typischerweise erstellt das LIS den Bericht, das kann aber auf Basis der Einzelbefunde auch vom KIS übernommen werden
	Content Consumer	O	O	X
LDA	Laboratory Device Automation
	Automation Manager	X	R	X
	Pre/Post Processor	X	X	R
	Analyzer	X	X	R
LBL	Laboratory Barcode Labeling
	Label Information Provider	X	R	X
	Label Broker	X		X
LPOCT	Laboratory Point Of Care Testing
	POC Data Manager	X	X	R
	POC Result Generator	X	X	R
	Order Filler	X	R	X
LCSD	Laboratory Code Sets Distribution				kann von KIS oder LIS übernommen werden; dann Zuordnung entsprechend; typischerweise wird dies vom LIS als Master übernommen
	Code Set Master	O	R	O
	Code Set Consumer	R	O	O

Infrastruktur

grundlegende Aktenkommunikation

An dieser Stelle sei zuerst auf das IHE-Cookbook verwiesen, in dem das Zusammenwirken der verschiedenen Profile detailliert erläutert wird.

Profil	Erklärung / Akteur	KIS	Subsystem	Archiv (DMS/PACS)	MPI	Kommentar
XDS	Cross Enterprise Document Sharing
	Identity Feed	verpfl.	opt.	X	R
	Document Source	verpfl.	empf.	X	X
	Document Consumer	empf.	empf.	X	X
	Repository	opt.	opt.	R	X
	Registry	nicht empf.	nicht empf.	opt.	nicht empf.
PIX	Patient Identifier Cross-Referencing
	Patient Identity Source	R	R	O	O
	Patient Identity Cross Reference Consumer	O	O	R	O
	Patient Identity Cross Reference Manager	X	X	X	R
PDQ	Patient Demographics Query
	Patient Demographics Supplier	X	X	X	RE
	Patient Demographics Consumer	R	R	R	O
XCA
	Initiating Gateway	O	O	O	O
	Responding Gateway	O	O	O	O
XUA++	Cross-Enterprise User Assertion
	???
CT	Consistent Time					wird in jedem Fall als Grundlage von allen benötigt
	Time Client	R	R	R	R
ATNA	Logging					wird in jedem Fall als Grundlage von allen benötigt
	Secure Node (grouped with any other actor)	R	R	R	R
	Audit Repository	O	O	O	O	Es muss ein System geben, dass diese Rolle übernimmt.
BPPC	Einwilligungserklärung					muss unterstützt werden
	???	R	R	R	X

Subsystem: Fachabteilungssystem

Anmerkungen

1. Bei XCA hängt die Erfordernis von der Architektur der Umsetzung ab, d.h. welche System stellvertretend die Rolle des Gateways übernehmen.
2. Offen ist noch die notwendige interne Kommunikation von Parametern, die bspw. vbei XDS notwendig wird.
3. Bie PDQ kann ein MPI durchaus auch wieder als Consumer agieren, um IDs von anderen MPIs zu bekommen.

erweiterte Aktenkommunikation: inhaltliche Aufbereitung

Die hier aufgelisteten Profile können bei einer Erweiterung der Aktenkommunikation zum Einsatz kommen:

Profil	Erklärung / Akteur	KIS	Subsystem	DMS	MPI	Kommentar
XDS-SD	Cross-Enterprise Sharing of Scanned Documents Content
	Content Creator	empf.	empf.	X	X
	Content Consumer	X	opt.	R	X

erweiterte Bildkommunikation

Profil	Erklärung / Akteur	KIS	Subsystem	DMS	MPI	Kommentar
XDS-I	XDS für Imaging (Bilddaten)
	???

Workflow-Unterstützung

Profil	Erklärung / Akteur	KIS	Subsystem	DMS	MPI
XDW	Cross Enterprise Document Workflow
	???				X

Allgemein

Profil	Erklärung / Akteur	KIS	Subsystem
PAM	Patient Administration Management
	Patient Demographics Supplier	R	X
	Patient Demographics Consumer	O	R
	Patient Encounter Supplier	R	X
	Patient Encounter Consumer	O	R
SVS	Sharing Value Sets
	Value Set Repository	O	O
	Value Set Consumer	O	O

Anmerkungen

1. Die Rolle des Consumers macht für jedes System Sinn, um Stammdaten aktualisieren zu können.

Pharmazie/Medikation

Profil	Erklärung / Akteur	KIS	Subsystem	??
HMW	Verschreibung im Krankenhaus
	???
CMPD	???
	???
PADV	???
	???
PRE	???
	???

Pathologie

Profil	Erklärung / Akteur	KIS	Pathologiesystem	KKR	EKR	Mammografie-Screening	eFA	Kommentar
APW	Anatomic Pathology Workflow
	Document Creator	O	R  ?	?	?	?	?
	Document Consumer	R?	O  ?	?	?	?	?
APRH	Anatomic Pathology Reporting to Public Health
	Document Creator	O	R  ?	?	?	?	?
	Document Consumer	R?	O  ?	R	R	R	R
APSR	Pathologiebefund (Anatomic Pathology Structured Reports)							APSR wird derzeit als Release 2.0 in Kooperation von IHE-AP und HL7-AP neu ausgearbeitet
	Document Creator	O	R  ?	x	x	x	x
	Document Consumer	RE	O  ?	O	O	O	R?

Legende:

• KKR = klinisches Krebsregister
• EKR = epidemiologisches Krebsregister

Onkologie

Profil	Erklärung / Akteur	KIS	KKR	EKR	Kommentar
QRPH-Ca	Krebsregistermeldungen (Quality Reporting to Public Health for Cancer)				QRPH-Ca wird derzeit als für die Bereiche (Realm) USA und Deutschland bei IHE erarbeitet. ADT und GEKID arbeiten aber weiterhin an proprietären Spezifikationen, die als XML-Basisdatensatz publiziert werden.
	Document Creator	R	O  ?	O ?
	Document Consumer	O	R  ?	R ?

Legende:

• KKR = klinisches Krebsregister
• EKR = epidemiologisches Krebsregister

Anwendungsszenarien

EFA on top of IHE

IHE Profil	IHE Akteur	EFA-Provider	EFA-Consumer (Direktanbindung)	EFA-Consumer (via Connector)	EFA-Connector
BPPC	...	verpfl.	verpfl.
XDS	Doc. Src.		verpfl.
XDS	Doc. Cons.		verpfl.
XDS	Registry	verpfl.	nicht empf.
XDS	Repository	verpfl.	verpfl.
..

Szenario	System	EFA-Provider	EFA-Consumer (Direktanbindung)	EFA-Consumer (via Connector)	EFA-Connector
grundlegende Aktenkommunikation	Archiv	verpfl.	opt.
..