<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="de">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Integration in der medizinischen Anwendung: Prozessbasierte Datenlogistik 1</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Sascha</forename><surname>Müller</surname></persName>
							<affiliation key="aff0">
								<orgName type="institution">Friedrich-Alexander-Universität Erlangen</orgName>
								<address>
									<addrLine>Nürnberg Martensstr. 3</addrLine>
									<postCode>D-91058</postCode>
									<settlement>Erlangen</settlement>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Rainer</forename><surname>Lay</surname></persName>
							<affiliation key="aff0">
								<orgName type="institution">Friedrich-Alexander-Universität Erlangen</orgName>
								<address>
									<addrLine>Nürnberg Martensstr. 3</addrLine>
									<postCode>D-91058</postCode>
									<settlement>Erlangen</settlement>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Christian</forename><surname>Meiler</surname></persName>
							<affiliation key="aff0">
								<orgName type="institution">Friedrich-Alexander-Universität Erlangen</orgName>
								<address>
									<addrLine>Nürnberg Martensstr. 3</addrLine>
									<postCode>D-91058</postCode>
									<settlement>Erlangen</settlement>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Stefan</forename><forename type="middle">Jablonski</forename><surname>Lehrstuhl Für Informatik</surname></persName>
							<affiliation key="aff0">
								<orgName type="institution">Friedrich-Alexander-Universität Erlangen</orgName>
								<address>
									<addrLine>Nürnberg Martensstr. 3</addrLine>
									<postCode>D-91058</postCode>
									<settlement>Erlangen</settlement>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Integration in der medizinischen Anwendung: Prozessbasierte Datenlogistik 1</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">76F12AFF3A1309FAEDF6F6CCC90B7DA8</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T10:34+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Zusammenfassung. Die möglichst optimale Integration klinischer Anwendungssysteme ist vital für den modernen Klinikbetrieb. Wir beschreiben einen Ansatz zur prozessorientierten Datenlogistik, der es erlaubt, das medizinische Personal entlang dem Behandlungsprozess mit notwendigen Daten zu versorgen. Durch Transformation graphischer Prozessmodelle in eine datenzentrierte Darstellung kann eine automatisierte Konfiguration von Kommunikationsservern erreicht werden. Im Vordergrund steht dabei die Datenversorgung der am Behandlungsprozess beteiligten Personen und nicht die direkte Unterstützung des Prozesses, wie sie durch Workflow-Management-Systeme erreicht wird. Der Ansatz wird in einer Fallstudie vorgestellt.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="de">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Einleitung</head><p>In der klinischen Datenverarbeitung besteht die Notwendigkeit zur Integration verschiedenster Anwendungssysteme mit dem Ziel existierende und zukünftige Behandlungsprozesse optimal zu unterstützen. Zwei grundlegend verschiedene Ansätze dominieren den Markt: Vollständig integrierte Krankenhausinformationssysteme (KIS), die mit einem holistischen Ansatz die Schnittstellenproblematik weitgehend zu vermeiden versuchen. Als Alternative existieren vor allem Kommunikationsserver-basierte Lösungen, die mit standardisierten Schnittstellen wie HL7 ("Health Level 7") [1] den Datenaustausch zwischen Einzelsystemen ermöglichen.</p><p>Im Fall der Kommunikationsserver stellt sich die Frage, wie die Datenflüsse optimal gestaltet werden können, um jederzeit hohe Datenverfügbarkeit zu gewährleisten und gleichzeitig die Prozesskosten zu minimieren. Eine Lösung für diese Problematik könnte eine prozessorientierte Vorgehensweise sein, welche beispielsweise die Datenverteilung entlang den Behandlungsstationen eines Patienten organisiert. Die Vorteile einer derartigen prozessbasierten Datenlogistik sind offensichtlich:</p><p>• Konfigurationen für Kommunikationsserver können automatisch aus umfassenden Prozessmodellen generiert werden. • Klinische Pfade können abgebildet und fallbasiert unterstützt werden.</p><p>• Vorhandene Infrastruktur kann effizienter genutzt werden, da sich die Lücke zwischen Anwendungswissen und der technischen Umsetzung, beispielsweise der Konfiguration eines Kommunikationsservers, schließt. Wir beschreiben im Folgenden einen Ansatz, der die genannten Vorteile der prozessbasierten Datenlogistik im Krankenhausbereich umsetzt. Dazu betrachten und bewerten wir im nächsten Abschnitt Basistechnologien wie Kommunikationsserver und Workflow-Management. Abschnitt 3 beschreibt unseren prozessbasierten Lösungsansatz und Abschnitt 4 illustriert schließlich mit einer Fallstudie unsere Methodik.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Basistechnologien</head><p>Die Basistechnologien Kommunikationsserver und Workflow-Management-Systeme (WfMS) werden im Folgenden kurz eingeführt und im Anwendungskontext des hier vorgestellten Ansatzes bewertet. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.1">Kommunikationsserver</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.2">Workflow Management</head><p>Workflow-Management-Systeme werden in verschiedensten Anwendungsbereichen eingesetzt und bieten eine umfassende Unterstützung von Anwendungsprozessen. Die Implementierung einer Workflow-Management-Anwendung erfolgt in zwei Schritten: In einem ersten Schritt muss ein Workflow-Modell erstellt und validiert werden. In einem zweiten Schritt wird ein solches Workflow-Modell zur Ausführungszeit instanziiert. Die Anwender interagieren mit dem System über eine Arbeitsliste, welche den am Prozess beteiligten Personen eine Liste der zur Ausführung bereitstehenden Aufgaben präsentiert <ref type="bibr" target="#b2">[3]</ref>.</p><p>Der Einsatz von WfMSen in Krankenhäusern hat eine Reihe von Vorteilen: WfMSe garantieren die koordinierte Ausführung von Prozessen mit Beteiligung von Anwendern und Systemen. Insbesondere der Datenaustausch zwischen den beteiligten Systemen wird organisiert, was WfMSe für den Einsatz im klinischen Umfeld prädestiniert. Ein oft genannter Vorteil von WfM ist die Eigenschaft, alle notwendigen Daten bei der Ausführung eines Prozessschrittes zur Verfügung zu stellen. Gerade in Kliniken kann dieses Merkmal aber auch sehr schnell ins Gegenteil umschlagen, wenn beispielsweise ein medizinischer Notfall die Abweichung vom vorgegebenen Workflow erzwingt. In diesem Fall muss das WfMS umgangen werden und es zeigt sich, dass sehr genau überlegt werden muss, welche Prozesse überhaupt mit Hilfe eines WfMS verwaltet werden können.</p><p>Durch die strenge und unflexible Ausführung von Prozessen ergibt sich eine Reihe von Nachteilen. Was in Anwendungsgebieten mit einer überschaubaren Anzahl weitgehend statischer Abläufe, wie beispielsweise dem Banken-oder Versicherungswesen ein gewichtiger Vorteil ist, wird im medizinischen Anwendungsbereich zur Achillesferse, da hier mit zahlreichen hochgradig variierenden Prozessen zu rechnen ist. Die resultierende Variantenvielfalt ist mit WfMS in der Praxis kaum zu erreichen, da diese auf eine strikte Ausführung der vorgegeben Prozesse ausgelegt sind und die Mächtigkeit der Modellierungssprache im Allgemeinen zu gering ist. Ansätze zur Flexibilisierung der Workflow-Ausführung (z.B. <ref type="bibr" target="#b3">[4]</ref>) sind zwar vorhanden, erhöhen aber auch die Komplexität des resultierenden Workflow-Modells.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.3">Bewertung</head><p>Sowohl Kommunikationsserver als auch WfMSe bieten Vor-und Nachteile beim Einsatz in Kliniken. WfMSe bieten die notwendigen Modellierungsmittel, um klinische Prozesse auf einem sinnvollen Abstraktionslevel umfassend zu beschreiben. Es zeigte sich aber auch, dass WfMSe oftmals auf einem zu restriktiven Ausführungsmodell basieren und die notwendige Flexibilität nicht liefern können.</p><p>Kommunikationsserver bieten Aufgrund der verwendeten Konfiguration auf Instanzebene keine problemspezifische Modellsicht, woraus schlechte Wartbarkeit und Lesbarkeit resultiert. Ihre Stärken liegen in dem einfachen und standardisierten Aufbau von Kommunikationsbeziehungen zwischen klinischen Systemen. Ausgehend von diesen Beobachtungen ist es wünschenswert, ein Konzept zu entwickeln, welches die Vorteile von beiden Ansätzen vereint und die Nachteile nicht übernimmt. Unser Konzept der prozessorientierten Datenlogistik folgt dieser Forderung.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Unser Lösungsvorschlag</head><p>Das vorliegende Konzept vereint die Vorteile von WfM und Kommunikationsservern und bietet eine Lösung für den Bereich der klinischen Kommunikation. Folgende Kernforderungen werden dabei erfüllt: Datenverfügbarkeit bei Ausführung eines Prozessschritts, abstrakte Beschreibung der klinischen Prozesse durch Prozessmodelle und Verwendung der Datenaustauschmechanismen von Kommunikationsservern (oder ähnlichen Ansätzen). Die Ergebnisse aus Abschnitt 2 lassen uns zwei Arten der Unterstützung von klinischen Prozessen erkennen: Modellierungs-und Kommunikationsunterstützung. Dies veranlasst uns zur Definition von zwei Ebenen: Der Modellierungsebene, welche eine abstrakte aber umfassende Definition der Kommunikationsbeziehungen enthält und der Kommunikationsebene, welche diese Spezifikationen umsetzt. WfMS haben konzeptionelle Stärken auf der Modellierungsebene und können dort verwendet werden. Zusätzlich kommen Teilkomponenten wie die Workflow-Ausführung auch in der Kommunikationsebene zur Geltung. Kommunikationsserver sind ein typischer Vertreter der Kommunikationsebene, aber auch andere Implementierungen können hier angesiedelt werden, wie beispielsweise der adaptive Replikationsmanager <ref type="bibr" target="#b4">[5]</ref>.</p><p>Wir bezeichnen unser Verfahren um klinische Prozesse zu modellieren und auszuführen als Prozessbasierte Datenlogistik <ref type="bibr">(PDL)</ref> </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Abb. 1. Die Abbildung eines Workflow-Schrittes in einen Datenlogistikschritt</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.">Die Datenlogistikprozesse müssen ausgeführt werden.</head><p>Für diese Aufgabe können verschiedene Techniken zum Einsatz kommen. Denkbar wären auch WfMSe mit leichten Modifikationen. Es bieten sich im klinischen Umfeld besonders Kommunikationsserver an, für die automatisiert eine Konfiguration aus dem datenzentrierten Modell erzeugt werden kann.</p><p>Die Hauptvorteile der PDL liegen in der Wiederverwendung bekannter und bewährter Techniken und in der erheblich vereinfachten und umfassenderen automatischen Konfiguration von Systemen der Kommunikationsschicht, wie beispielsweise Kommunikationsserver.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Fallstudie: Vom Workflow-Modell zur prozessorientierten Datenlogistik</head><p>In  &lt;PEK xsi:type="process" Name="store diagnostic data in glaucoma register" ID="REP_ORTR(12675)"&gt; &lt;Attribut Name="ParentID" Wert="REP_ORTP(8348)" /&gt; &lt;data_container_out Name="inner_ocular_pressure" ID="REP_ORTP(8350)" /&gt; &lt;data_container_out Name="blood_pressure" ID="REP_ORTP(8318)" /&gt; &lt;/PEK&gt; Um von dieser Beschreibung zu einer gültigen Konfiguration für das verwendete Wrapper-Framework YAWA ("Yet Another Wrapper Framework") <ref type="bibr" target="#b6">[7]</ref>  </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Fazit</head><p>Dieses Papier präsentiert einen Ansatz zur prozessbasierten Konfiguration des Datenaustausches zwischen klinischen Systemen. Ziel ist dabei eine Versorgung des medizinischen Personals mit relevanter Information entlang des Behandlungsprozesses. Aus graphisch modellierten Prozessmodellen werden hierzu Datenlogistikprozesse abgeleitet. Eine Fallstudie verdeutlicht den Ansatz.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Literatur</head></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Abb. 2 .</head><label>2</label><figDesc>Abb. 2. Der Selbsttonometrie ProzessKurz zum medizinischen Hintergrund: Einige Glaukompatienten (Grüner Star) müssen den Augeninnendruck (IOP, inner ocular pressure) über einen längeren Zeitraum selbstständig messen. Um den Ablauf zu optimieren, können die Patienten ihre Daten mit Hilfe eines automatischen Telefoniesystems an die Klinik übermitteln. Dabei muss der Patient sich authentifizieren und dann seine Daten eingeben. Vom automatischen Telefoniesystem werden die Daten an das KIS (Abrechnung) und an die zentrale Glaukomdatenbank (Forschung) weitergeleitet. Ein Augenarzt überprüft regelmäßig die Daten und verordnet eine Therapie oder eine weitere Untersuchung.In diesem vereinfachten Beispiel soll die Datenübertragung des automatischen Telefoniesystems in das KIS und das zentrale Glaukomregister unter Verwendung der PDL Methodologie konfiguriert werden.Das abgebildete Prozessmodell ist nicht nur eine graphische Repräsentation des Prozesses. Das verwendete Modellierungswerkzeug (I&gt;PM<ref type="bibr" target="#b5">[6]</ref>) erlaubt eine umfassende, aspektorientierte Beschreibung mit allen für die PDL notwendigen Daten.Um die Beschreibung für die Konfiguration verwenden zu können, wird ein XML Export des Modells erzeugt. Dieser wird mit Hilfe eines XSLT Skripts in ein passendes datenzentriertes XML Modell gewandelt. Im folgenden Ausschnitt ist ein entsprechend transformierter Prozessschritt zu sehen.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_1"><head></head><label></label><figDesc>. Es fußt auf den Konzepten des WfM, verzichtet jedoch auf die Ausführung, indem es sich auf die Ableitung von Kommunikationsregeln aus einem Prozessmodell beschränkt. PDL unterscheidet sich weiterhin vom strikten Modell des Workflow Management, indem es unauffällig im Hintergrund dem Anwender die für seine nächsten Schritte benötigten Daten bereitstellt; eine Interaktion mit dem Anwender ist nicht notwendig. Der Anwender behält so volle Handlungsfreiheit und profitiert zugleich von hoher Datenverfügbarkeit. Folgende Schritte charakterisieren PDL:</figDesc><table><row><cell cols="5">System" zu "Glaucoma Register" transportiert. Die Problematik der</cell></row><row><cell cols="5">Datentransformation bedingt durch unterschiedliche Formate, Terminologien und</cell></row><row><cell cols="5">Ontologien in Quell-und Zielsystem ist hier nicht näher betrachtet. Eine</cell></row><row><cell cols="5">Beschreibung der Datencontainer in dieser Hinsicht ist jedoch vorgesehen.</cell></row><row><cell></cell><cell>IOP</cell><cell></cell><cell>IOP</cell></row><row><cell>process step</cell><cell>Blood Pressure</cell><cell>data container</cell><cell>Blood Pressure</cell></row><row><cell cols="2">record glaucoma data</cell><cell></cell><cell cols="2">store diagnostic data</cell></row><row><cell>Patient</cell><cell>Telephone System (TS)</cell><cell></cell><cell>Assistant Medical Technician</cell><cell>Glaucoma Register (GR)</cell></row><row><cell>initiator</cell><cell>used application</cell><cell></cell><cell></cell></row><row><cell></cell><cell>IOP</cell><cell></cell><cell>IOP</cell></row><row><cell></cell><cell cols="2">Blood Pressure</cell><cell>Blood Pressure</cell></row><row><cell></cell><cell></cell><cell cols="2">MOVE DATA</cell></row><row><cell></cell><cell>from :</cell><cell cols="2">Telephone System</cell></row><row><cell></cell><cell>to :</cell><cell cols="2">Glaucoma Register</cell></row><row><cell></cell><cell cols="2">incoming phone call</cell><cell>YAWA</cell></row><row><cell cols="5">1. Die klinischen Prozesse müssen aufgenommen und in einem Workflow-Modell</cell></row><row><cell cols="2">dokumentiert werden.</cell><cell></cell><cell></cell></row><row><cell cols="5">Analog zum Workflow-Management steht am Anfang eine umfassende</cell></row><row><cell cols="5">Prozessaufnahme, die auf verfügbaren Informationen basiert, wie z.B.</cell></row><row><cell cols="5">medizinische Leit-und Richtlinien, medizinisches Personal, EDV-Systemland-</cell></row><row><cell>schaft, etc.</cell><cell></cell><cell></cell><cell></cell></row><row><cell cols="5">2. Das Workflow-Modell muss in ein datenzentriertes Modell umgewandelt werden.</cell></row><row><cell cols="5">Mit dieser Transformation werden die beteiligten Systeme und die zwischen ihnen</cell></row><row><cell cols="5">ausgetauschten Daten in den Mittelpunkt der Betrachtung gestellt. Man kann</cell></row><row><cell cols="5">daraus sehr leicht die Regeln zur Beschreibung der Datenlogistik ableiten. Ein</cell></row><row><cell cols="5">Workflow-Modell wird in ein datenzentriertes Modell gewandelt (siehe Abb. 1),</cell></row><row><cell cols="5">indem aus jedem Datenfluss zwischen zwei Prozessschritten ein Datenlogistik-</cell></row><row><cell cols="5">schritt erzeugt wird. Dieser Datenlogistikschritt benötigt die ausgehenden</cell></row><row><cell cols="5">Datencontainer des vorhergehenden Workflow-Schritts und die eingehenden</cell></row><row><cell cols="5">Datencontainer des nachfolgenden Workflow-Schritts. Zusätzlich werden noch die</cell></row><row><cell cols="5">Systeme der beteiligten Workflow-Schritte benötigt, da diese den Speicherungsort</cell></row><row><cell cols="5">der zu transportierenden Daten spezifizieren. In unserem Bespiel (vgl. Abb. 1) wird</cell></row><row><cell cols="5">aus den Schritten "record glaucoma data" und "store diagnostic data" ein</cell></row><row><cell cols="5">Datenlogistikschritt, der die Daten "IOP" und "Blood Pressure" von "Telephone</cell></row></table></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_2"><head></head><label></label><figDesc>diesem Abschnitt beschreiben wir, wie man ein Workflow-Modell in eine gültige Konfiguration für ein System der Kommunikationsebene, in unserem Beispiel ein Wrapper-Framework, transformiert. Der verwendete, vereinfacht dargestellte Prozess (Abb. 2) entspringt einem Projekt aus dem Sonderforschungsbereich 539 der Universitätsaugenklinik Erlangen-Nürnberg.</figDesc><table><row><cell></cell><cell></cell><cell cols="2">Prozess: Self-Tonometry</cell><cell></cell><cell></cell><cell></cell></row><row><cell cols="3">Measure specification//</cell><cell>external entry</cell><cell cols="2">electronic health record//</cell><cell></cell></row><row><cell cols="3">Measure specification//</cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell></cell><cell></cell><cell></cell><cell>patient id//</cell><cell></cell><cell></cell><cell></cell></row><row><cell></cell><cell></cell><cell></cell><cell>comparison data//</cell><cell></cell><cell></cell><cell></cell></row><row><cell>Optronic C</cell><cell>man.</cell><cell></cell><cell>inner ocular pressure//</cell><cell>store</cell><cell></cell><cell cols="2">patient id//</cell></row><row><cell cols="2">measure IOP</cell><cell>inner ocular pressure//</cell><cell>patient id//</cell><cell>diagonstic data in</cell><cell></cell><cell cols="2">inner ocular pressure//</cell></row><row><cell>patient</cell><cell>-/-</cell><cell></cell><cell>automatic telephony system</cell><cell cols="2">glaucoma register -/-</cell><cell></cell></row><row><cell></cell><cell></cell><cell></cell><cell>record</cell><cell></cell><cell></cell><cell></cell><cell>creat the</cell></row><row><cell></cell><cell></cell><cell></cell><cell>telephone call</cell><cell></cell><cell></cell><cell></cell><cell>finding</cell></row><row><cell></cell><cell></cell><cell></cell><cell>-/-</cell><cell></cell><cell></cell><cell></cell><cell>medic</cell><cell>-/-</cell></row><row><cell>b.-p. meter</cell><cell>man.</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>Measure</cell><cell></cell><cell></cell><cell></cell><cell>update</cell><cell></cell><cell></cell></row><row><cell>blood pressure patient</cell><cell>-/-</cell><cell>heart rate// blood pressure//</cell><cell>blood pressure// heart rate//</cell><cell>patient data in HIS</cell><cell>-/-</cell><cell cols="2">medical history// patient id//</cell></row><row><cell></cell><cell></cell><cell></cell><cell>patient id//</cell><cell></cell><cell></cell><cell></cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>finding//</cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>patient id//</cell></row><row><cell></cell><cell></cell><cell></cell><cell cols="2">therapy proposal//</cell><cell></cell><cell></cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell>patient id//</cell><cell></cell><cell>propose</cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>therapy</cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>medic</cell><cell>-/-</cell></row><row><cell></cell><cell></cell><cell></cell><cell>external exit</cell><cell></cell><cell></cell><cell></cell></row></table></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_3"><head></head><label></label><figDesc>zu kommen, sind folgende Schritte notwendig: 1. Lokalisierung, d.h. die Auswahl der verwendeten Systeme, 2. Erzeugen der Konfiguration für das Wrapper Framework (eine Teilkonfiguration ist im folgenden Ausschnitt zu sehen), 3. Erzeugung von ECA Regeln. Anhand dieser Fallstudie konnte exemplarisch gezeigt werden, dass durch eine Änderung des Workflow-Modells automatisiert eine Anpassung der Konfiguration des Kommunikationssystems erfolgen kann.</figDesc><table><row><cell>&lt;EXTRACTOR&gt;&lt;VIEWS&gt;</cell></row><row><cell>&lt;pressure&gt;SELECT * FROM All_Pressure_Data&lt;/pressure&gt;</cell></row><row><cell>&lt;/VIEWS&gt;&lt;/EXTRACTOR&gt;</cell></row><row><cell>&lt;RESULTPROCESSOR&gt;</cell></row><row><cell>&lt;TARGETS&gt;&lt;IOP&gt; &lt;TARGET_RELATION&gt;IOP&lt;/TARGET_RELATION&gt;</cell></row><row><cell>&lt;ATTRIBUTES&gt;</cell></row><row><cell>&lt;ID TYPE="Integer"/&gt;</cell></row><row><cell>&lt;Exam_Date TYPE="Date" FORMAT="yyyy-MM-dd"/&gt;</cell></row><row><cell>&lt;Patient_ID TYPE="String"/&gt;</cell></row><row><cell>..</cell></row><row><cell>&lt;/ATTRIBUTES&gt;</cell></row><row><cell>&lt;/IOP&gt;&lt;/TARGETS&gt;</cell></row><row><cell>&lt;/RESULTPROCESSOR&gt;</cell></row></table></figure>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="1" xml:id="foot_0">Der Sonderforschungsbereich 539: "Glaukome einschließlich Pseudoexfoliations-Syndrom (PEX)" wird unterstützt von der Deutschen Forschungsgemeinschaft (DFG).</note>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">HL7: A Protocol for the Interchange of Healthcare Data</title>
	</analytic>
	<monogr>
		<title level="m">Progress in Standardization in Health Care Informatics</title>
				<editor>
			<persName><forename type="first">W</forename><forename type="middle">E</forename><surname>Hammond</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">G</forename><forename type="middle">J E</forename><surname>De Moore</surname></persName>
		</editor>
		<imprint>
			<publisher>IOS Press</publisher>
			<date type="published" when="1993">1993</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">Eine Taxonomie für Kommunikationsserver im Krankenhaus</title>
		<author>
			<persName><forename type="first">M</forename><surname>Lange</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Prokosch</surname></persName>
		</author>
		<author>
			<persName><forename type="first">W</forename><surname>Hasselbring</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Informatik, Biometrie und Epidemiologie in Medizin und Biologie</title>
		<imprint>
			<biblScope unit="volume">30</biblScope>
			<biblScope unit="issue">1</biblScope>
			<biblScope unit="page" from="21" to="34" />
			<date type="published" when="1999-01">1999. 1/1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<monogr>
		<author>
			<persName><forename type="first">S</forename><surname>Jablonski</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Bußler</surname></persName>
		</author>
		<title level="m">Workflow management -modeling concepts, architecture and implementation</title>
				<meeting><address><addrLine>London</addrLine></address></meeting>
		<imprint>
			<publisher>International Thomson Computer Press</publisher>
			<date type="published" when="1996">1996</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">A Framework for Dynamic Changes in Workflow Management Systems</title>
		<author>
			<persName><forename type="first">M</forename><surname>Reichert</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Dadam</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">DEXA Workshop</title>
				<imprint>
			<date type="published" when="1997">1997</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">Adaptive Replikationsstrategie für heterogene, autonome Informationssysteme</title>
		<author>
			<persName><forename type="first">H</forename><surname>Niemann</surname></persName>
		</author>
		<author>
			<persName><forename type="first">W</forename><surname>Hasselbring</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Tagungsband zum 14. GI-Workshop Grundlagen von Datenbanken</title>
				<imprint>
			<date type="published" when="2002">2002</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<monogr>
		<ptr target="http://www.prodato.de/software/processmanager" />
		<title level="m">i&gt;ProcessManager</title>
				<imprint>
			<publisher>ProDatO GmbH</publisher>
			<date type="published" when="2003-12-03">2003-12-03</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<analytic>
		<title level="a" type="main">Yawa -Yet Another Wrapping Architecture</title>
		<author>
			<persName><forename type="first">M</forename><surname>Lang</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Lay</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">BTW</title>
		<imprint>
			<date type="published" when="2003">2003</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
