Unterstützung der Choreographie von SOM-Workflows durch WS-CDL

Inhaltsverzeichnis

Abbildungsverzeichnis

Listingverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Methodische Grundlagen zu WS-CDL und SOM
2.1 Das Choreographiekonzept im Kontext verteilter Systeme
2.2 Die Web Service Choreography Description Language
2.2.1 Ziele von WS-CDL
2.2.2 Der statische Teil von WS-CDL - Typdefinitionen
2.2.3 Der dynamische Teil von WS-CDL - Choreographies und Activities
2.3 Workflowmodellierung mit Hilfe des Semantischen Objektmodells
2.3.1 Architekturrahmen und Vorgehensmodell des SOM
2.3.2 Das Vorgangsereignisschema
2.3.3 Das Vorgangsobjektschema

3 Einführung in die Fallstudie
3.1 Merkmale eines Medizinischen Versorgungszentrums
3.2 Geschäftsprozessmodell des MVZCare

4 Modellbasierte Ableitung der WS-CDL-Spezifikationen aus dem Vorgangsobjektschema
4.1 Anforderungen an das VOS
4.2 Typspezifikationen des WS-CDL-Dokuments
4.2.1 Spezifikation von RoleTypes und ParticipantTypes
4.2.2 Spezifikation der RelationshipTypes
4.2.3 Spezifikation der InformationTypes
4.2.4 Spezifikation von Tokens und TokenLocators
4.2.5 Spezifikation von ChannelTypes
4.3 Spezifikation der Choreographies des WS-CDL-Dokuments
4.3.1 Abgrenzen von Subchoreographien
4.3.2 Spezifikation der Variables und Relationships in einer Choreography
4.3.3 Spezifikation von Interactions
4.3.4 Spezifikation der Ablaufstruktur in WS-CDL

5 Open-Source Tool-Unterstützung für WS-CDL
5.1 Pi4SOA
5.1.1 Choreography Description Designer
5.1.2 Szenario-Editor
5.1.3 Bewertung
5.2 WS-CDL Eclipse
5.2.1 Einführung in WS-CDL Eclipse
5.2.2 Bewertung
5.3 WS-CDL+ Execution
5.3.1 Choreographien mit Hilfe der Ausführungsengine simulieren
5.3.2 Bewertung
5.4 Fazit und Auswahl eines Editors zur Durchführung der Fallstudie

6 Validierung der Ergebnisse anhand der Fallstudie MVZCare
6.1 Das VOS des MVZCare
6.1.1 Rollenzuweisungen und Beziehungen
6.1.2 Spezifikation weiterer Basisdatentypen
6.1.3 Spezifikation des Nachrichtenflusses
6.2 Bewertung der Fallstudienergebnisse

7 Kritik und Alternativen zu WS-CDL
7.1 Kritik an WS-CDL
7.2 BPEL4Chor: Choreographiebeschreibungen auf Grundlage von WS-BPEL
7.3 Bewertung von BPEL4Chor im Vergleich zu WS-CDL

8 Fazit und Ausblick

9 Literaturverzeichnis

Abbildungsverzeichnis

Abb. 1 Choreographie versus Orchestrierung (Peltz 2003, S. 47)

Abb. 2 UML Sequenzdiagramm: Radiologische Untersuchung

Abb. 3 WS-CDL Activities (Barros et al. 2005, S. 8)

Abb. 4 SOM Unternehmensarchitektur (Ferstl und Sinz 2008, S.193)

Abb. 5 SOM Vorgehensmodell (Ferstl und Sinz 2008, S.195)

Abb. 6 VEZ Medizinische Behandlung

Abb. 7 Generisches Leistungsnetz aus dem Bereich der medizinischen Versorgung (Pütz et al. 2009, S. 6)

Abb. 8 IAS des Fallbeispiels MVZ Care

Abb. 9 VES des Fallbeispiels MVZCare

Abb. 10 Metamodell VOS (Ferstl und Sinz 2008, S. 228)

Abb. 11 VOS Radiologische Untersuchung

Abb. 12 Relationships und VariableDefinitions für das Orthopädie-Radiologie- Beispiel

Abb. 13 Ablaufstruktur des Orthopädie-Radiologie-Beispiels

Abb. 14 VOS des MVZCare

Abb. 15 Rollen und Beziehungen MVZCare

Abb. 16 ChannelTypes des MVZCare

Abb. 17 InformationTypes des MVZCare

Abb. 18 ChoreographyFlow des MVZ

Listingverzeichnis

Listing 1 Abstrakte Syntax für RoleTypes und ParticipantTypes (Kavantzas et al. 2005)

Listing 2 RoleTyps und ParticipantTypes des Orthopädie-Radiologie-Beispiels

Listing 3 Abstrakte Syntax für RelationshipTypes (Kavantzas et al. 2005)

Listing 4 RelationshipType des Orthopädie-Radiologie-Beispiels

Listing 5 Abstrakte Syntax für InformationTypes (Kavantzas et al. 2005)

Listing 6 InformationTypes für das Orthopädie-Radiologie-Beispiel

Listing 7 Abstrakte Syntax für Token und TokenLocators (Kavantzas et al. 2005)

Listing 8 Token und TokenLocators für das Choreographie-Radiologie-Beispiel

Listing 9 Abstrakte Syntax für ChannelTypes (Kavantzas et al. 2005)

Listing 10 ChannelTypes für das Orthopädie-Radiologie-Beispiel

Listing 11 Abstrakte Syntax für ein choreography-Element

Listing 12 Abstrakte Syntax für eine Interaction

Tabellenverzeichnis

Tabelle 1 Vergleich WS-CDL und BPEL4Chor (Decker und Overdick 2006, und Decker et al. 2007, 302) 50

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Hochflexible Geschäftsprozesse stellen erhöhte Anforderungen an die Flexibilität der sie unterstützenden Anwendungssysteme. Ihre Charakterisierung wird anhand von drei Kriterien vorgenommen: Planbarkeit des Prozesses, zeitliche Überlappung von Run-Time und Build-Time sowie dem Grad der Kontextintensivität (Pütz et al. 2009, S. 1).

Für eine adäquate IT-Unterstützung dieser Geschäftsprozesse bietet sich eine serviceorientierte Anwendungslandschaft an, in der das Zusammenspiel einzelner Services zur Unterstützung verschiedener Geschäftsprozesse flexibel gestaltbar ist.

Das Semantische Objektmodel (SOM) kann zur Modellierung eines solchen hochflexiblen Geschäftsprozesses benutzt werden. Konkrete Ablaufstrukturen auf Anwendungssystemebene werden dabei in einem Vorgangsobjektschema (VOS) erfasst. Auf oberster Ebene der Serviceimplementierung ist WS-CDL als XMLbasierte Beschreibungssprache für das Zusammenspiel und die Choreographie autonomer Services als Standard zu nennen.

Ziel dieser Arbeit ist es, eine Brücke zwischen einem Anwendungssystemmodell nach SOM-Methodik und einem WS-CDL-Dokument zu schlagen. Dazu sollen die semantischen Gemeinsamkeiten beider Modelle ausgearbeitet werden und anschließend in eine Methodik zur Ableitung von WS-CDL-Spezifikationen aus einem VOS einfließen.

Die Methodik selbst soll mit Hilfe einer Fallstudie aus dem Bereich der Medizini- schen Versorgung validiert werden. Dazu werden zunächst zur Auswahl stehende Werkzeuge zur Unterstützung von WS-CDL vorgestellt, namentlich die Pi4soa Tool- Suite, WS-CDL Eclipse und WS-CDL+ Execution. Hiervon wird eines zur Verwen- dung empfohlen werden, das auch zur Durchführung der Fallstudie verwendet werden soll.

Im letzten Teil der Arbeit werden noch Kritikpunkte an WS-CDL angeführt und mit BPEL4Chor eine alternative Choreographiesprache vorgestellt.

2 Methodische Grundlagen zu WS-CDL und SOM

Dieses Kapitel soll einige methodische Grundlagen zu WS-CDL (Kavatzas et al. 2005) und dem Semantischen Objektmodell (SOM) (Ferstl und Sinz 2008 S. 192 - 229 ) vermitteln.

2.1 Das Choreographiekonzept im Kontext verteilter Systeme

Die Beschreibung der Komposition von Webservices kann aus zwei sich überlappenden Betrachtungswinkeln erfolgen, dem Choreographie- und dem Orchestrierungskonzept (Peltz 2003, S. 46). Der Begriff Choreographie kann daher am besten in Abgrenzung zu Orchestrierung erläutert werden.

„Die Service-Orchestrierung steht für die Veröffentlichung eines technischen Prozesses, der über verschiedene andere Services läuft, die in der Regel bei demselben Service-Mediator registriert sind“ (Mathas 2008, S. 211). Das Zusam- menwirken der verschiedenen Services wird also hierarchisch von einer zentralen Instanz gesteuert (Ferstl und Sinz 2008, S. 430). Dabei werden sowohl der Nachrich- tenaustausch als auch interne Vorgänge der Services beschrieben (Barros et al 2005, S. 5), wobei sich diese Beschreibung auf die Sicht des Service-Anbieters beschränkt. Als wichtigster Standard zur Service-Orchestrierung ist in diesem Zusammenhang WS-BPEL zu nennen (Hohpe 2007, S. 444).

Eine Choreographie in verteilten Systemen beschreibt hingegen das aus Außensicht beobachtbare Verhalten verschiedener kollaborierender Parteien zur Erreichung eines gemeinsamen Ziels aus einem globalen Betrachtungswinkel. Alle beteiligten Services agieren dabei als gleichberechtigte autonome Teilkomponenten; es gibt also keinen Service, der die Kontrolle über den Ablauf des Prozesses hat (Barros et al. 2005, S. 2f.). Hauptaugenmerk bei dieser Art der Systembeschreibung liegt auf den jeweiligen Serviceschnittstellen und den auszutauschenden Nachrichten (Mathas 2008, S 205). Serviceinterne Aktivitäten werden nicht berücksichtigt. Der Zustand einer Choreographie ergibt sich daher aus den bisher gesendeten Nachrichten der beteiligten Teilnehmer (Holpe 2007, S. 443f.). Ferner umfasst eine Service- Choreographie dabei auch einzuhaltende Bedingungen und vorkommende Abhängig- keiten für die erfolgreiche Durchführung des Prozesses (Barros et al. S. 2). Der derzeitige Favorit für die Spezifikation von Webservice-Choreographien ist WS- CDL (Holpe 2007, S. 444).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Choreographie versus Orchestrierung (Peltz 2003, S. 47)

Folgendes Beispiel in Anlehnung an die Fallstudie dieser Arbeit, die in Kapitel 3 eingeführt wird, soll das Konzept hinter dem Begriff Choreographie erläutern. In einem Medizinischen Versorgungszentrum gibt es sowohl eine Fachabteilung Orthop ä die als auch eine Fachabteilung Radiologie. Die Kooperation zwischen diesen Abteilungen erfolgt über das Verhandlungsprinzip, die internen Vorgänge sind für den jeweils anderen also transparent. Für das gemeinsame Ziel eines radiologischen Ergebnisses muss zunächst die Orthop ä die eine solche Anfrage an die Radiologie schicken. Die Choreographie befindet sich nun in einem Zustand „Warte auf Radiologieantwort“. Wie die Radiologie intern die Anfrage verarbeitet und die Untersuchung durchführt, ist aus Sicht einer Choreographie nicht relevant. Die nächste nach außen sichtbare und damit relevante Aktivität ist die Übermittlung des radiologischen Ergebnisses an die Orthop ä die.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: UML Sequenzdiagramm: Radiologische Untersuchung

2.2 Die Web Service Choreography Description Language

Die Web Service Choreography Description Language (WS-CDL) ist eine XML- basierte Sprache, die von der Web Services Choreography Working Group des W3C entwickelt wurde und seit 2004 in der Version 1.0 vorliegt (Kavantzas et al. 2005). WS-CDL basiert formal auf der algebraischen Sprache pi-Kalk ü l (Bichler und Setzer 2008) und geht unter anderem aus der Modellierungssprache Web Service Choreo graphy Interface (WSCI) hervor (Austin et al. 2004).

Ein WS-CDL-Dokument kann als Vertrag zwischen beliebig vielen kollaborierenden Webservices verstanden werden, in dem die Austauschabfolge von Nachrichten und möglichen Ausnahmebehandlungen festgehalten wird (Kavantzas et al. 2005).

2.2.1 Ziele von WS-CDL

Bei der Entwicklung von WS-CDL wurden folgenden Ziele verfolgt (Kavantzas et al. 2005):

- Wiederverwendbarkeit: Choreographien sollten in verschiedenen Kontexten mit unterschiedlichen Teilnehmern wiederverwendet werden können.
- Kooperation: Choreographien sollten die Kooperation unabhängiger Teilnehmer mit Hilfe von Nachrichtenaustauschbeziehungen beschreiben.
- Kooperation mehrerer Teilnehmer: An einer Choreographie sollten beliebig viele Services teilnehmen können.
- Semantik: Eine WS-CDL-Dokument sollte in seiner semantischen Bedeutung für einen Menschen durch Dokumentationen verständlich sein.
- Kombinierbarkeit: Choreographien sollten in beliebiger Form zu neuen Choreographien kombinierbar sein.
- Modularität: Choreographien sollten so modular gestaltet werden, dass sie als Teilkomponenten in andere Choreographien eingebunden werden können.
- Informationsgetriebene Kollaborationen: Der Status der Choreographie und das Verhalten der Teilnehmer sollte durch die bereits ausgetauschten Nachrichten beeinflusst werden.
- Informationsabgleich: Teilnehmer einer Choreographie sollten die Möglichkeit haben, globale Informationen und Variablen miteinander auszutauschen und abzugleichen.
- Ausnahmebehandlung: In einer Choreographie sollte auf Ausnahmen und Fehler im Ablauf angemessen reagiert werden können.
- Transaktionalität: Beteiligte Services sollten die Koordination des Ergebnisses der gemeinsamen Choreographie durch eigene Regeln und Ziele gewährleisten können.
- Kompatibilität zu anderen Standards: Die Kompatibilität zu komplementären Spezifikationen wie WS-CAF, WSS, WS-BPEL und weiteren sollte gewähr- leistet werden.

2.2.2 Der statische Teil von WS-CDL - Typdefinitionen

Das Wurzelelement eines WS-CDL-Dokumentes ist das Package. RoleTypes, ParticipantTypes, RelationshipTypes, ChannelTypes und InformationTypes, Tokens und TokenLocators dienen der Spezifikation der beteiligten Entitäten und Rollen der Kollaboration. Sie können damit dem statischen Teil eines WS-CDL-Dokuments zugeschrieben werden (Fredlung 2006, S. 108).

InformationType: InformationTypes definieren die Arten von Informationen, die zwischen RoleTypes ausgetauscht werden können (Kavantzas et al. 2005). Im Eingangsbeispiel bräuchte man zwei InformationTypes, ein RadRequestType und ein RadResponseType. Möglich wäre auch ein RadResponseFaultType für einen auftretenden Fehlerfall bei der Untersuchung in der Radiologie.

Token und TokenLocator: Ein Token kann als Alias für spezielle Informationen innerhalb eines InformationTypes verwendet werden. Ein TokenLocator spezifiziert mittels einer XPath-Angabe den möglichen Zugriff auf diese Information innerhalb eines InformationTypes (Kavantzas et al. 2005).

RoleType: Services können in eine oder mehrere „Rollen“ schlüpfen, die ein oder mehrere Verhaltensweisen repräsentieren (Kavantzas et al. 2005). Im Eingangsbeispiel gibt es zwei RoleTypes, eine RadRequestorRole (Orthopädie) und eine RadSupplierRole (Radiologie).

ParticipantType: Ein ParticipantType gruppiert alle RoleTypes, die zwingend zusammen durch einen Service realisiert werden müssen (Kavantzas et al. 2005). Im Beispiel könnten zwei Webservices Orthopädie (RadRequestorRole) und Radiologie (RadSupllierRole) als Participants auftreten.

RelationshipType: Die Zuordnung zwischen zwei interagierenden RoleTypes wird in einem RelationshipType erfasst (Kavantzas et al. 2005).

ChannelType: Ein ChannelType beschreibt jenes Medium, das zwei RoleTypes zur Kommunikation verwenden (Kavantzas et al. 2005). Jedoch wird im ChannelType lediglich der antwortende und nicht der anfragende RoleType identifiziert (Fredlund 2006, S. 108). Der konkrete Service wird über eine Referenz angegeben. ChannelTypes sind auf diese Weise der Konnektor zwischen den WS-CDL- Spezifikationen und den auszuführenden Operationen, die beispielsweise auf einem WSDL-Interface definiert sind (Kavantzas et al. 2005).

2.2.3 Der dynamische Teil von WS-CDL - Choreographies und Activities

Ein Package kann ein bis beliebig viele Choreographies enthalten. Eine Choreogra- phie in WS-CDL umfasst eine Reihe von Activities, die von unterschiedlichen Participants ausgeführt werden. (Barros et al. 2005, S. 7). Zu einer Activity gehören eine Menge von Austauschbeziehungen zwischen RoleTypes und Variables, die für das datenflussabhängige Verhalten der Choreographie notwendig sind. Dabei ist jede Variable einem bestimmten Participant zugeordnet, auf welche ausschließlich die RoleTypes Zugriff haben, die der Participant implementiert (Kavantzas et al. 2005). Bei Barros et al. (2005. S. 7-9) werden die Activities in drei Gruppen unterteilt:

Structural Activities: Unter strukturelle Aktivitäten fallen die Strukturelemente sequence, parallel und choice. Diese Elemente enthalten eine Menge von Unteraktivitäten. In einer SequenceActivity werden diese Unteraktivitäten sequentiell durchlaufen, während bei einer ParallelActivity ein oder mehrere Aktivitäten parallel ausgeführt werden können. Im Kontext von hochflexiblen Geschäftsprozessen ist aber vor allem die ChoiceActivity interessant, die es erlaubt, die eine oder andere Unteraktivität - abhängig vom Wert einer lokalen Variable oder dem Zustand der Choreographie - auszuführen (Barros et al. 2005, S. 8).

Workunits: Eine Workunit beschreibt eine von einer Bedingung abhängige und wiederholbare Aktivität. Die Ausführung einer Workunit hängt von verschiedenen Variables ab. Mit der GuardCondition wird geprüft, ob die Activity überhaupt ausgeführt wird. Solange die Repetition C ondition „true“ ergibt, wird die Ausführung der Activity daraufhin wiederholt. In einer weiteren BlockCondition kann spezifiziert werden, dass die Auswertungen von Repetition C ondition und GuardCondition solange geblockt werden, bis spezielle andere Variablen verfügbar sind (Kavantzas et al. 2005).

Basic Activities: Unter diese Activities fallen Interaction, NoAction, SilentAction, Assign und Perform.

- Die Interaction ist sicherlich die wichtigste der hier angeführten Activities. Eine Interaction kann für drei Arten des Nachrichtenaustausches verwendet werden: für eine Anfrage (request), für eine Antwort (response) und für eine Anfrage, die eine Antwort erwartet (request-response). Für jede Interaction werden die teilnehmenden Participants, die auszutauschenden InformationTypes und die zu verwendenden Channels (Instanz eines ChannelTypes) spezifiziert. Neben Nachrichten können Interactions auch dazu verwendet werden, Channel- Variablen zwischen Services zu übertragen (Kavantzas et al. 2005). - Die Activites NoAction und SilentAction führen zu keiner nach außen hin sichtbaren Veränderung des Zustands der Choreographie (Barros et al 2005, S. 8).
- Ein AssignActivity wird verwendet, um den Wert einer Variable einer anderen Variable innerhalb eines RoleTypes zuzuweisen (Kavantzas et al. 2005).
- Eine PerformActivity stößt das Ausführen einer anderen Choreographie an, die innerhalb der auszuführenden Choreographie eingebettet ist (Kavantzas et al. 2005).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: WS-CDL Activities (Barros et al. 2005, S. 8)

2.3 Workflowmodellierung mit Hilfe des Semantischen Objektmodells

Untersuchungsobjekte dieser Arbeit sind Workflows, welche mit Hilfe der objekt- und prozessorientierten SOM-Methodik nach Ferstl und Sinz modelliert wurden (Ferstl und Sinz 2008, S. 192-229). Diese Methodik wird für das volle Verständnis dieser Arbeit als bekannt vorausgesetzt. An dieser Stelle werden daher für die Arbeit relevante Teilkonzepte der SOM-Methodik lediglich in stark vereinfachter Form vorgestellt.

2.3.1 Architekturrahmen und Vorgehensmodell des SOM

Das SOM ist ein umfassender Ansatz zur Modellierung betrieblicher Informationssysteme. Die Unternehmensarchitektur der SOM-Methodik umfasst drei Modellebenen, die sowohl nach Außen- und Innensicht, als auch nach Aufgaben- und Aufgabeträgerebene voneinander abgegrenzt werden.

Das Vorgehensmodell bei der SOM-Methodik berücksichtigt eine Struktur- wie auch eine Vorgangssicht. Repräsentiert wird es durch das sogenannte V-Modell.

Für die Ebene der Geschäftsprozessmodellierung werden die Diagramme IAS (Leistungs- und Lenkungssicht) und VES (Ablaufsicht) bereitgestellt. Auf Ebene der Anwendungssystemspezifikationen lassen sich auf Grundlage dieser Diagramme methodisch das Konzeptuelle Objektschema (KOS) und das Vorgangsobjektschema ableiten (VOS) (Ferstl und Sinz 2008, S 192-196).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: SOM Unternehmensarchitektur Abb. 5: SOM Vorgehensmodell

(Ferstl und Sinz 2008, S.193) (Ferstl und Sinz 2008, S.195)

Workflowdefinitionen in Form eines VOS stehen am Ende der Modellierung der Ablaufsicht im SOM. Neben der Definition eines Zielsystems auf Ebene des Unternehmensplans umfasst die Modellierung der Ablaufsicht insbesondere noch das VES auf Geschäftsprozessebene.

2.3.2 Das Vorgangsereignisschema

Das Vorgangsereignisschema spezifiziert das Verhalten eines Geschäftsprozesses anhand von Aufgaben, die Diskursweltobjekten bzw. Umweltobjekten (Ferstl und Sinz 2008, S. 211) zugeordnet sind und Ereignisbeziehungen zwischen diesen Aufgaben. Ein betriebliches Objekt umfasst dabei eine Menge von Aufgaben mit zusammengehörigen Sach- und Formalzielen, die auf einem gemeinsamen Aufgabenobjekt durchgeführt werden (Ferstl und Sinz 2008, S. 200).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: VEZ Medizinische Behandlung

Das VES korrespondiert mit einem zugehörigen IAS, das den Geschäftsprozess aus Lenkungs- und Leistungssicht beschreibt (Ferstl und Sinz 2008, S 197f.).

2.3.3 Das Vorgangsobjektschema

Das Vorgangsobjektschema (VOS) dient der Darstellung des Verhaltens eines Anwendungssystems, ermöglicht also eine Visualisierung der innerhalb des Geschäftsprozessmodells stattfindenden Workflows eines oder mehrerer betrieblicher Objekte, deren Realisierung durch maschinelle Aufgabenträger ermöglicht werden soll (Ferstl und Sinz 2008, S 225).

Ausgangspunkt bei der Erstellung eines VOS ist ein Ausschnitt des zugrunde- liegenden VES. Jede betriebliche Aufgabe wird zunächst in einen Vorgangsobjekttyp überführt und jede Ereignisbeziehung (beinhaltet auch Transaktionen) in eine interacts_with -Beziehung. In weiteren Schritten werden nicht automatisierbare Vorgangsobjekttypen (VOT) entfernt und den verbliebenden VOTs Nachrichten sowie Operatoren in Form von Teilgraphen des korrespondierenden KOS zugeordnet (Ferstl und Sinz 2008, S 226).

3 Einführung in die Fallstudie

In diesem Abschnitt der Arbeit soll die Fallstudie eingeführt werden, mit deren Hilfe die in Kapitel 4 folgenden Ableitungen der WS-CDL-Spezifikationen validiert wird. Die Fallstudie wird durch den Bayerischen Forschungsverbund „Dienstorientierte ITSysteme für hochflexible Geschäftsprozesse“ (kurz: forFlex) zur Verfügung gestellt. Gegenstand der Fallstudie ist der Ausschnitt eines generischen Geschäftsprozessmodells eines Medizinischen Versorgungszentrums.

3.1 Merkmale eines Medizinischen Versorgungszentrums

„Medizinische Versorgungszentren sind fachübergreifende ärztlich geleitete Einrich- tungen, in denen Ärzte (…) als Angestellte oder Vertragsärzte tätig sind“ (§ 95 Abs. 1 S. 1 SGB V).

Im Rahmen von forFlex wurden verschiedene Medizinische Versorgungszentren untersucht und auf Grundlage der Ergebnisse und deduktiven Überlegungen ein generisches Leistungsnetz erstellt, welches vier unterschiedliche Leistungssegmente beinhaltet (Pütz et al. 2009, S. 5-7):

Abbildung in dieser Leseprobe nicht enthalten

Abb. 7: Generisches Leistungsnetz aus dem Bereich der medizinischen Versorgung (Pütz et al. 2009, S. 6)

Für die Fallstudie wird ein spezifisches Leistungsnetz MVZCare angenommen, das wie folgt definiert ist:

MVZCare: MLB= {Othopädie}, MLC={Radiologie}

3.2 Geschäftsprozessmodell des MVZCare

Auf Grundlage dieses spezifischen Leistungsnetzes wurde ein Geschäftsprozessmodell gemäß SOM-Methodik entwickelt, welches die betrieblichen Objekte Orthop ä die, Radiologie, Annahme, Vorplanung und Abrechnung sowie die Umweltobjekte Patient und Krankenkasse umfasst.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 8: IAS des Fallbeispiels MVZ Care

Der Patient wendet sich mit einer Terminanfrage an den Annahmeagenten, bestehend aus Annahme und Vorplanung. Dieser tritt daraufhin in Verhandlungen mit der Orthop ä die und weist dem Patienten als Ergebnis dieser Verhandlungen einen vorläufigen Termin bei einem Arzt zu. Bei Eintreffen des Patienten im MVZ nimmt die Annahme die Patientendaten auf und führt eine Kurzanamnese durch. Ferner erfolgt nun die finale Arztzuweisung an die Orthop ä die. Beispielsweise könnte es sein, dass aufgrund von Terminabsagen oder Notfällen die Einhaltung des ursprünglichen Termins nicht mehr möglich ist. Der Annahmeagent ist somit für sämtliche Anbahnungs- und Vereinbarungstransaktionen mit dem Patienten verant- wortlich. Die Leistungserbringung am Patienten wird indes von der Medizinischen Leistung, bestehend aus Orthop ä die und Radiologie, erbracht. Die Orthop ä die kann den Patienten zur Radiologie überweisen. Über Durchführungstransaktionen werden die erbrachten Leistungen bei der Abrechnung zu einer Gesamtrechnung zusammengeführt. Diese ist entweder vom Patienten selbst oder von dessen Krankenkasse¹ zu entrichten.

Alle beteiligten betrieblichen Objekte in diesem Fallbeispiel arbeiten autonom und interagieren ausschließlich nach dem Verhandlungsprinzip (Ferstl und Sinz 2008, S. 202).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 9: VES des Fallbeispiels MVZCare

4 Modellbasierte Ableitung der WS-CDL Spezifikationen aus dem Vorgangsobjektschema

Im diesem Kapitel wird erläutert, wie Schritt für Schritt aus SOM-Workflows eine WS-CDL-Spezifikation abgeleitet werden kann.

Zur Modellierung von Workflows wird im SOM das VOS verwandt. Dem Metamodell für die Spezifikation von Anwendungssystemen entsprechend der SOMMethodik kann man entnehmen, dass ein VOS aus aufgabenspezifischen Objekttypen, interacts_with -Beziehungen, sowie typspezifischen Operatoren und Attributen besteht (Ferstl und Sinz 2008, S. 228).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 10: Metamodell VOS (Ferstl und Sinz 2008, S. 228)

Das Metamodell aus Abb. 10 wurde mit Hilfe des Meta-Metamodells nach Ferstl und Sinz (2008, S. 133) modelliert.

Darüber hinaus gehört zu einem vollständigen VOS auch immer die Einbindung des korrespondierenden KOS, da etwa die Attribute der Konzeptuellen Objekttypen (KOT), die den Worklflow einer betrieblichen Aufgabe realisieren, auch den Zustandsraum des entsprechenden VOTs bilden (Ferstl und Sinz 2008, S. 225).

Zur Veranschaulichung der einzelnen Schritte soll im Folgenden das Eingangsbeispiel als Teilausschnitt der Fallstudie aufgegriffen werden.

[...]

---

¹

Für diese Fallstudie wurde das Umweltobjekt Kassen ä rztliche Vereinigung nachträglich durch Krankenkasse ersetzt, um später das Konzept des Passing von Channels in WS- CDL anwenden zu können.