Ein Metamodellansatz zum Aufbau dynamisch erweiterbarer

Universität Erlangen-Nürnberg
Institut für Informatik
Lehrstuhl für Datenbanksysteme
Arbeitsgruppe InTech
Ein Metamodellansatz zum Aufbau dynamisch erweiterbarer
Modellierungssysteme
Î Prozess- und Datenintegration in klinischen Anwendungen
ƒ
à Beispielszenario: Medizin
à Anwendungs- und Datenintegration
à Aspekteorientierte Prozessmodellierung
Stefan Jablonski
Sascha Müller
Aufgabe und Lösungskonzept
ƒ
Anwendungen
à Prozessmodelle
à Wissensmanagement
ƒ
Umsetzung
à Metadatenverwaltung mit Repositorium
30. Juni 2005
Aufgabenstellung
Ein Projektkontext
ƒ Sonderforschungsbereich 539:
"Glaukome einschließlich Pseudoexfoliationssyndrom (PEX)"
à Arbeitsgruppe InTech des Lehrstuhls für Datenbanksysteme
à Augenklinik der Universität Erlangen-Nürnberg
ƒ Glaukom: Degeneration des Augennervs
ƒ Arbeitssschwerpunkte
à Applikationsintegration
à Datenintegration
Aufnahme der Papilla
(Augenhintergrund)
aufgenommen mit einer
speziellen Modalität
30. Juni 2005
2
Aufgabenstellung
Anforderungen an die Integration
ƒ Applikationsintegration
à Zusammenwirken der Applikationen (Modalitäten, KrankenhausInformationssystem (KIS), Befundarbeitsplatz, etc.)
à Kompakte, vollständige, anwendungsspezifische Modellierung
à Berücksichtigung anwendungsbezogener Besonderheiten
ƒ Datenintegration
à Viele sehr unterschiedliche Datenquellen (Modalitäten, KrankenhausInformationssystem (KIS), Befundarbeitsplatz, etc.)
à Nicht nur Datensammlung sondern auch Datenaustausch
ƒ Allgemeine Anforderungen
à Qualität
à Sicherheit
30. Juni 2005
3
Aufgabenstellung
Lösungsansatz
ƒ Modellbasiert
à Wiederverwendung, Generalisierung, Verifikation, Analyse
ƒ Prozessorientiert
à Vollständigkeit, Komplexität
ƒ Datenbankbasiert
à Konsistenz, Persistenz, Auswertbarkeit
ƒ Berücksichtigung von Standards, Normen, Erfahrungen,
spez. Sichtweisen
à Klinische Pfade (evidenzbasiert) Æ "template"
à Darstellung
ƒ
ƒ
ƒ
'Customized' (angepasst)
'Compact' (kompakt)
'Comprehensible' (verständlich)
Lösungsmethode
Domänen-spezifische Anpassung eines generischen Prozessmodells
30. Juni 2005
4
Lösungskonzept
Framework: iPM4med
ƒ iPM4med (integrated ProcessManager for medical applications)
à Perspektiven-orientiertes Prozessmodell
à Repositorium-basiertes Metamodell
ƒ Perspektiven-orientiertes Prozessmodell
à
à
à
à
à
à
Funktionale Perspektive (Funktion, Inhalt)
Verhaltensorientierte Perspektive (Kontrollfluss)
Informationsbezogene Perspektive (Ein-/Ausgangsdaten, Datenfluss)
Organisatorische Perspektive (Agenten)
Operationale Perspektive (Applikationen, Systeme)
…
Beispiel eines Modellierungskonstrukts: "Prozessschritt"
HRT Daten
PatID
HRT Bild
Eine HRT Aufnahme machen
MTA
30. Juni 2005
HRT
5
ƒ iPM4med (integrated ProcessManager for medical applications)
à Perspektiven-orientiertes Prozessmodell
à Repositorium-basiertes Metamodell
ƒ Repositorium-basiertes Metamodell
à
à
à
à
Perspektiven sind nicht ins Prozessmodell "eingebrannt"
Prozessskelett interpretiert zugeordnete Perspektiven
Metamodelle für Perspektiven und Modellierungskonstrukte
Neue Modellierungskonstrukte werden eingeführt, indem – für alle
betroffenen – Perspektiven definiert wird:
ƒ
ƒ
ƒ
Syntax (Struktur, Attribute)
Semantik (Interpretation)
Präsentation (Mod. & Exe.)
Funktion
Verhalten
Prozessskelett
Information
Organisation
Operation
…
30. Juni 2005
Modellierungskonstrukt
Lösungskonzept
Framework: iPM4med
Syntax
Semantik
Präsentation
6
Beispielkonstrukt
iPM4med: Data Logistics
PatID
HRT Daten
HRT Daten
HRT Bild
HRT Bild
Eine HRT Aufnahme machen
MTA
HRT
Log Rec
HRT Aufnahme abspeichern
Arzt
ER Glaukomreg.
HRT Daten
PatID
HRT Bild
Eine HRT Aufnahme machen
MTA
HRT
HRT Daten
HRT Bild
Log Rec
MOVE DATA <Form,
Form Trans,
Trans Ont>
from: <Source>
Source
to: <Sink>
Sink
HRT Aufnahme
30. Juni 2005
YAWA
7
Beispielkonstrukt
iPM4med: Checkliste
Stellung, Lage und Länge Bein
Arzt/OPA
-
Cave Begleitverletzungen
Arzt/OPA
-
Druck- und Klopfschmerz
Arzt/OPA
Hämatom. Weichteilbefund
-
Arzt/OPA
ggf. Infektionszeichen nach OP
Arzt/OPA
Periphere Durchblutung: Motorik, …
-
Arzt/OPA
Herz, Kreislauf, ZNS
-
Arzt/OPA
-
-
…
Arzt/OPA
•
Stellung, Lage und Länge Bein
•
Druck und Kopfschmerz
•
Hämatom, Weichteilbefund
•
Periphere Durchblutung, Motorik, …
•
Cave Begleitverletzungen
•
ggf. Infektionszeichen nach OP
•
Herz, Kreislauf, ZNS
•
…
-
PatID
Klinische Untersuchung
durchführen (OP)
Arzt/OPA
30. Juni 2005
8
Anwendung
iPM4med: Prozesse für medizinische Anwendungen
30. Juni 2005
9
Beispielkonstrukt
iPM4med: Wissensmanagement
ƒ
Goals
à
à
ƒ
Method
à
à
à
ƒ
(Re)use produced data as knowledge pool
Simple to use, but highly effective method to classify data
Introduce Meta Data
Define rules to specify what and how Meta Data is assigned
Integrate data into a central knowledge base (i>KM)
New Construct
à
“Tagging Rule”
Rule:
assign physician
Rule:
assign patient
Patient ID
HRT print
HRT print
HRT data
HRT data
Take an HRT image
medical assistant
30. Juni 2005
HRT device
Rule:
set process step
Log record
Store image in glaucoma register
physician
Glaucoma Register
10
Anwendung
Wissensmanagement - Überblick
guideline/directive
selection
documents
semantic search
semantic
search engine
information export
web server
process modeling
process execution
i>PM
PDL
information retrieval
i>KM
multi dimensional
assignment
i>KM
Knowledge Publishing Pipeline
30. Juni 2005
11
Anwendung
Wissensmanagement - Überblick
guideline/directive
selection
documents
Process
semantic search
semantic
search engine
30. Juni 2005
information export
web server
process modeling
process execution
i>PM
PDL
Model,
Rules
information retrieval
i>KM
Meta data,
Data
multi dimensional
assignment
Assigned,
annotated
Data
i>KM
12
Anwendung
Prozesse finden und auswählen
ƒ
Find basic process structures
ƒ
Typical sources
à
à
à
Medical guidelines and directives
Established processes (e.g. ISO certification documents)
Interviews with experts
ƒ
Often processes are already established
ƒ
Result:
Decision which process to support
Typical problem:
Find an agreement among
the domain experts (physicians)
30. Juni 2005
13
Anwendung
Prozesse modellieren
30. Juni 2005
14
Anwendung
Prozessbasierte Datenlogistik (PDL): Konzept
1. Derive data logistics processes
ƒ
ƒ
Clinical process as basis
Take “localized” configuration data
out of repository
Modeling phase
2. Configure data transport system
à
YAWA (wrapper framework)
clinical
process
model
abstract data
specifications
application
infrastructure
concrete data
specifications
PDL
workflow
description
3. Handle application data
à
à
Data transportation/access
Data transformation
30. Juni 2005
Execution phase
15
Anwendung
Prozessbasierte Datenlogistik (PDL): Ausführung
Modeling
Execution
30. Juni 2005
16
Anwendung
Verknüpfung mit der Wissensbasis
Secretary
Multidimensional Knowledge Space
Mapping is done
using the attached
Meta data!
Kowa
printout
Mapping
MTA
Staff
Meta data
Knowledge
Elements
HRT
image
physician
Meta data
FDT
report
Discharge
Letter
Hierarchical
Structures
30. Juni 2005
HRT
KOWA
Tools
FDT
Meta data
Meta data
17
Werkzeug: Integrated Knowledge Manager
Anwendung
Search panel:
Category selection,
full text search,
external systems
30. Juni 2005
Process tree:
Central
organization
structure
Search results:
Documents, multi
media data,
hyper-links
18
Anwendung
Prozessmodellierung und Wissensmanagement
Fusion: Knowledge Management at conceptual level
à
à
ƒ
(Re)use of existing documents
à
à
à
ƒ
New domain specific modeling construct: Tagging rules
Specification within process model
Higher level of acceptance: well known
Increased productivity: no need to learn new formats/syntax
No effort to create “new” documents
Availability during process pathway execution
à
à
à
Knowledge pool automatically filled
iKM central point of information
Intuitive search method
30. Juni 2005
19
Umsetzung
Repositorium: Definition, Abgrenzung zu Datenbanken
ƒ Datenbank
4 Language Level
(3 Meta Level)
3 Language Level
(2 Meta Level)
!Tabelle, !Domäne,
!Attribut, !Bedingung
Katalog
2 Language Level
(1 Meta Level)
?Konzept. Schema
(Tabellen, …)
Daten
1 Language Level
(Object Level)
?Daten (z.B. Befunde,
Untersuchungen, MRT)
ƒ Repositorium
4 Language Level
(3 Meta Level)
3 Language Level
(2 Meta Level)
?Prozessskelett,
?Perspektive, ?Konstrukt
Katalog
2 Language Level
(1 Meta Level)
?Prozessmodelle,
?Modellierungskonstrukte
Daten
1 Language Level
(Object Level)
?Prozessinstanzen,
?Organisationseinheit
Datenspeicher mit anpassbaren Systemkatalog, in welchem
Daten und Metadaten (2. LL) gleichberechtigt behandelt werden
30. Juni 2005
20
OMG MOF
MOF Metadaten Architektur
ƒ M3 (Meta-Meta Model / MOF layer)
à
Umfasst Meta-Meta-Metadaten,
welche die M2-Daten und sich selbst
beschreiben (Selbst-Beschreibung)
ƒ M2 (Meta-Model layer)
à
Umfasst Meta-Metadaten, welche die
M1-Daten beschreiben
ƒ M1 (Model layer)
à
Umfasst Metadaten, welche die M0Daten beschreiben
ƒ M0 (Information layer)
à
30. Juni 2005
Umfasst die Rohdaten einer
Anwendung (Prozesse, Tupel,
Objekte, etc.)
21
OMG MOF
MOF Model Package*
*) vereinfacht
depends on
es to
con
stra
ins
ModelElement
co
nt
ai
ns
h
attac
Tag
Namespace
Import
Feature
Constraint
TypedElement
aliases
s
ralize
gene
ty
of
is
Generalizeable
Element
Constant
Behavioral
Feature
Package
StructureField
StructuralFeature
Parameter
AssociationEnd
refers to
Classifier
pe
Association
Class
Datatype
Operation
Exception
Attribute
Reference
can raise
Primitive
Type
30. Juni 2005
Structure
Type
Enumeration
Type
Collection
Type
Alias
Type
22
Lösungskonzept
M2-Modell: iPM Meta-Modell
*
_generalizes
Generalizable
Element
*
Classifier
Class
Fraction
Modelling
Construct
_hat
1
*
_presents
Presentation
30. Juni 2005
23
M3
MEV
Mt
FROM M2::->M,
TYPEm(M) Mt,
M3
M2
Constant
(M 2)
M->C, C->A^D,
M Mi, C Ci,
Ci->Ai^Di,
M
MEV
C
MEV
Aj
MEV
M2
M1
TYPEm(Ai) At
Mi
M1
A
Type
SELECT *
Type
Lösungskonzept
iRM (integrated RepositoryManager): mSQL
Inst.Var
Ci
Inst. Var
Ai
MEV
ƒ Schema-Exploration (horizontal), Schema-Discovery (vertikal)
(reflection, introspection, intercession)
ƒ Durchgängige, gleichartige Behandlung von Daten und Metadaten
Î Aufheben der "schematic heterogeneity"
ƒ Deklarative Anfrageformulierung
Î Schema-Unabhängigkeit
30. Juni 2005
Î mSQL
24
Lösungskonzept
mSQL: Beispielanfragen
ƒ
Gib mir alle Prozesse im System
à
ƒ
SELECT
FROM
WHERE
class.name, attr.name, defined_in.name
M2::IPMPackage -> class, class -> attr, M2::IPMPackage -> defined_in
class IN ( SELECT * FROM M1::MedPack -> elements, TYPEm(elements) elementsType )
AND attr IN defined_in;
Gib mir die Namen aller "Bubble"-instanzen, sowie die Namen und die Anzahl der
Parameter ihrer Methoden
à
SELECT
FROM
WHERE
ƒ
*
M2::IPMPackage:Bubble bubbleInstances
bubbleInstances.name = 'process';
Gib mir den Namen und die Namen der Attribute aller Elemente des IPMPackages , sowie
die Elemente in denen diese Attribute definiert worden sind, sofern diese Elemente
Instanzen im Extent M1::MedPack haben
à
ƒ
SELECT
FROM
WHERE
constructInstances.name, attributes.name, attributes.numberOfParameters
M2::IPMPackage:ModelConstruct -> constructs constructInstances, constructInstances -> attributes,
TYPE(attributes) attributeTypes
M2::IPMPackage:Method IN attributeTypes;
Gib mir den Namen, die Farbe und die Form aller darzustellender Instanzen von
ModelingConstruct im Extent M1::MedPack
à
SELECT
FROM
WHERE
30. Juni 2005
constructInstances.name, presentationInstances.color, presentationInstance.shape
M2::IPMPackage:ModelingConstruct -> constructs constructInstances,
M2::IPMPackage:Component -> components componentsInstances,
M2::IPMPackage:Presentation -> presentations presentationInstances
constructInstances._hat componentsInstances AND
componentsInstances._presents presentationInstances AND
constructInstances IN M1::MedPack AND presentationInstances.isVisible = true;
25
Lösungskonzept
mSQL: Anfragebearbeitung, Ausführungsplan
ƒ Anfrage
à
SELECT
FROM
*
M2::->M, TYPEm(M) Mt, M->C, C->A, M Mi, C Ci, Ci->Ai^Di, TYPEm(Ai) At
ƒ Neue Typen an Variablen (high order query language)
à
Instanz-Variable (von SQL), Klassen-Variable, Package-Variable, Attribut-Variable,
Datentyp-Variable, …
Î Erweiterung der Relationenalgebra
ƒ Ausführungsplan
30. Juni 2005
26
Lösungskonzept
mSQL: Konsistenz
ƒ Strukturelle Konsistenz
à Sind Objekte konform zur Definition ("well-formed")
ƒ
Komposition, Generalisierung, Assoziation (Kardinalität, Partizipation, etc.)
à Bei einer Modifikation
ƒ
ƒ
Ist die Operation erlaubt?
Können alle Instanzen an die modifizierte Objekt-Definition angepasst werden?
Manipulation (M2)
Model Element
Required Action (M1)
Deletion
Package
Deletion
Class
Deletion
Association
Deletion
Attribute (classifier-level)
Remove the attribute from the class proxy
Deletion
Attribute (instance-level)
Remove the attribute from all instances
Change
Containment Hierarchy
Roll back the RT
Change
Generalization Hierarchy
Roll back the RT
Change
Attribute Type
Change
Association End Type
Creation
Attribute (classifier-level)
Add a new attribute to the class proxy
Creation
Attribute (instance-level)
Add a new attribute to all class instances (initialized with default values)
Delete the package proxy (including all contents)
Delete the class proxy (including all instances)
Delete the association proxy (including all links)
Roll back the RT if values are incompatible
Roll back the RT, if the new type is not a super-type of the old one
ƒ Operationale Konsistenz
à Nebenläufiger Zugriff durch Repository-Transaktionen
30. Juni 2005
27
Lösungskonzept
mSQL: Isolation
ƒ Repositorium soll zentrale Komponente einer Anwendung sein
Î
Mehrbenutzerbetrieb
ƒ Sperren auf mehreren Schichten (anders als bei DBMS)
Î
komplexere Sperrverfahren
ƒ Kumulative Sperren – "instance lattice"
à Sperren von Instanz-Objekten auf allen darunter liegenden Ebenen
à Sperren von abhängigen Objekten
ƒ Sperren von Modell-Elementen
à
à
à
à
Vererbungshierarchie {gS, gX}
Kompositionshierarchie {cS, cX}
Assoziationen
Meta-Hierarchie {iS, iX}
30. Juni 2005
28
Lösungskonzept
Beispiel zur (Anwendungs- und) Datenintegration
mSQL-Anfrage:
Anfrage: "Alle Untersuchungsergebnisse"
SELECT
FROM
WHERE
30. Juni 2005
a.patient, a.durchgang, a.wert, b.attr_b, c.wert, d.attr_d
M1::Modalitaet_1:Untersuchungen a,
M1::Modalitaet_2:Untersuchungen b, b -> attr_b,
M1::Modalitaet_3 -> elem_c c,
M1::Modalitaet_4:Untersuchungen d, d -> attr_d
a.patient = b.patient AND a.patient = c.patient AND
a.patient = attr_d AND a.durchgang = attr_b AND
a.durchgang = elem_c AND a.durchgang = d.durchgang;
29
Zusammenfassung & Ausblick
Resümee
ƒ Framework-Architektur
iPM4mb
i???Mgr
iArchMgr
iPM4med
iProcessManager
iRepositoryManager
30. Juni 2005
30