130125_FINSOZ UAG Personendaten Protokoll

1. UAG-Sitzung „Interoperabilität-Personendaten“ am 25.01.2013 in Kassel
Teilnehmer
Name
Vorname
Titel
Franz
Dominik
Miro
Janik
Reinhard
Evangelische Stiftung Neuerkerode
Kahlert
Timo
Redline DATA GmbH
Medenwaldt
Jens
Redline DATA GmbH
Müller
Roland
pro dokument
Ripke
Torsten
Ristok
Hellmut
euregon AG
Schmidt
Tobias
LHW Kreis Waldeck Frankenberg
Steigauf
Walter
Unitek GmbH
Wolff
Dietmar
Dr.
Prof. Dr.
Einrichtung/Firma
MICOS GmbH
ConsultSocial GbR
1. Kurze Vorstellung des Verbands durch Herrn Prof. Dr. Dietmar Wolff, Hochschule Hof
=> siehe 130125_FINSOZ UAG Personendaten Wolff.pdf
2. Kurze Vorstellungsrunde
=> daraus skizziert Herr Wolff die Situation der anwesenden Teilnehmer hinsichtlich der heute
behandelten Thematik - siehe 130125_FINSOZ UAG Personendaten Situation der Teilnehmer.pdf
3. Aus der aktuellen Verbandsarbeit - Prof. Dr. Dietmar Wolff, Hochschule Hof
=> siehe 130125_FINSOZ UAG Personendaten Wolff.pdf
4. Erfahrungen aus der Durchführung einer Adressbereinigung - Tobias Schmidt, LHW Kreis
Waldeck-Frankenberg
=> Präsentation siehe 130125_FINSOZ UAG Personendaten Schmidt.pdf
•
•
•
Projekt zur Bereinigung von 30.000 Adressen in einem Gesamtsystem für Finanzen, Personal,
Produktion und Leistungsabrechnung/Dokumentation
Auffälligkeiten in den Daten
- unkorrekte Datensätze
- unbrauchbare Datensätze - Falscheingaben oder "missbrauchte" Felder
Herausforderungen
FINSOZ e.V. · Fachverband Informationstechnologie in Sozialwirtschaft und Sozialverwaltung · Vorstandsvorsitzender Frank Nelles
Bankverbindung Kto. 1168600 BLZ 100 205 00 · Bank für Sozialwirtschaft · St.-Nr. 27/653/51680 · Handelsregister VR 29966 B
-
•
•
Freiberufler und Einzelfirmen, z.B. bei Ärzten Gemeinschaftspraxis und dann die einzelnen
Ärzte
Überlegungen
- mehr Vorgaben für die Adresseingabe
Diskussion
- die Adresse im zentralen Adresspool kann maschinell bereinigt werden, Problematik der
doppelten Objekte in den Fachsystemen
5. Erfahrungen mit der Datenintegration als Anbieter einer sich in der Regel integrierenden
Anwendung - Jens Medenwaldt, Redline DATA, Timo Kahlert, Redline DATA
=> Darstellung der Erfahrungen siehe 130125_FINSOZ UAG Personendaten Redline DATA.pdf
•
•
•
•
•
•
•
•
stationäre Suchtkrankenhilfe und als Anbieter in diesem Umfeld stets Integrator
- Bewilligungen kommen elektronisch vom Leistungsträger zurück
- viele Einrichtungen haben keine Festlegung eines führenden Systems
verdeutlicht die Problematik an dem eigentlich noch recht einfachen Fall der Schnittstelle zur
Finanzbuchhaltung
Beispiele aus den komplexeren Anbindungen
- zur Aufnahme vorgesehener Patient
- Unterbrechung der Behandlung
- Dubletten
- "Kunde fragt immer, warum er für Name, Vorname, Geburtsdatum und Adresse jedesmal
neu für eine Schnittstelle bezahlen muss"
Anforderungen daraus
Identifizierung der Personen - Norwegen: Personennummer
Identifizierung der Behandlung
Patiententyp
Datenformat
sicherer Transfer
Protokollierung
Rückmeldungen
Harmonisierung von Systematiken - möglichst nicht bilaterale Kommunikation,
sondern Information zentral bereitstellen, anderes System nimmt diese und
interpretiert sie nach eigenen Regeln
Randthemen
- Art und Umfang der Daten
- Berechtigungen
- widersprüchliche Daten - funktioniert gut mit einer Master/Slave Systematik
skizzierte Lösungen
- ein zentrales Gesamtsystem mit seinen Vor- und Nachteilen
- Schaffung eines "Daten-Buses", Identifikation einer Person
technische Basis der Umsetzung
- zeigen eine XML-Realisierung einer standardisierten Schnittstelle für Fremdsysteme
- einfache spezialisierte Schnittstellen sind i.d.R. am unproblematischsten
- dateibasiert => sinnvoll und zurzeit am meisten verwendet oder eher SOAP o.ä.?
- es gibt Lösungen für die Fragestellungen (z.B. Master Patient Index in HL7) => warum
nicht genutzt?
Diskussion
- wo werden die Adressen geprüft, im abgebenden, annehmenden System oder in der
Schnittstelle?
Plädoyer für die Prüfung im aufnehmenden System
FINSOZ e.V. · Fachverband Informationstechnologie in Sozialwirtschaft und Sozialverwaltung · Vorstandsvorsitzender Frank Nelles
Bankverbindung Kto. 1168600 BLZ 100 205 00 · Bank für Sozialwirtschaft · St.-Nr. 27/653/51680 · Handelsregister VR 29966 B
6. Problemlösungsansatz zur Datenvereinheitlichung aus Projekten im ECM-Umfeld - Walter
Steigauf, Unitek
seine Vorschläge siehe Datenmatrix_V2.xls
• notwendige Vorgehen aus seiner Sicht
- zunächst einmal definieren, welche Daten wir für einen Patienten sehen
- nicht nur für die Grunddaten, sondern auch die Abrechnungsdaten
• Diskussion
- nicht nur die low level Adresse, sondern auch die darauf basierenden Objekte
standardisieren
- es gibt schon Standards, wie man so etwas aufbaut, aber oft zu umfassend (Hr. Steigauf
schildert das Beispiel aus dem elektronischen Rechnungsaustausch) => können wir
daraus das nehmen, was wir brauchen?
Verfügbare Standards zur Personendatenbeschreibung - Prof. Dr. Dietmar Wolff, Hochschule Hof
=> siehe 130125_FINSOZ UAG Personendaten Wolff.pdf
•
Diskussion
- aus HL7 einen Extrakt machen, der für die Branche praktikabel ist
- alternative Ausgangsbasis/möglicher Subset könnte die eGK sein
- aus der HL7-Definition kann sich jeder Anbieter dann das nehmen, was er braucht
und wenn für ihn notwendige Daten nicht drin sind, müssten die Daten im
empfangenden System angemahnt und nachgearbeitet werden
- dazu müsste dem Datensatz eine "Patientenrolle" (wie dieser Datensatz zu interpretieren
ist) mitgegeben werden
kann ich aus der Rolle schließen, dass auch die Basisdaten bestimmten Regeln
entsprechen oder bedeutet das nur, dass bestimmte Felder vorhanden sind?
- die annehmenden Systeme sollten dazu auch definieren, was sie an Daten brauchen
sie müssten prüfen, ob die Daten für ihre Bedürfnisse richtig sind
- die Verantwortung für die Sinnhaftigkeit der Eingaben würde nach wie vor bei der
Einrichtung liegen
- ggf. könnte es bestimmte "leichtgewichtige" Prüfungen geben (Mindestkriterien)
- welche Anwendungsfälle von Datenaustausch gibt es?
es sollten Use Cases beschrieben werden und nicht die Universalschnittstelle für
alle Fälle definiert werden
dies könnte auf Basis der definierten Felder erfolgen - wo werden die in den
verschiedenen Use Cases benötigt
- muss es eine bidirektionale Kommunikation sein oder reicht zunächst die unidirektionale
Datenübergabe?
das wäre ein zweiter Schritt, sich über die Prozesse zu unterhalten, das könnte auf
Basis von iHE erfolgen - dort gibt es schon entsprechende Middleware-Konzepte
und erste Systemrealisierungen
- FINSOZ sollte etwas dem HL7 CDA vergleichbare definieren, um nicht nur die
Stammdaten, sondern auch die Bewegungsdaten zu übernehmen
darüber könnte man auch Rückmeldungen z.B. von Fachverfahren an das zentrale
System abbilden
- wir wollen im ersten Ansatz nicht Daten zentral für alle zur Verfügung stellen, sondern
7. Plan zum weiteren Vorgehen
FINSOZ e.V. · Fachverband Informationstechnologie in Sozialwirtschaft und Sozialverwaltung · Vorstandsvorsitzender Frank Nelles
Bankverbindung Kto. 1168600 BLZ 100 205 00 · Bank für Sozialwirtschaft · St.-Nr. 27/653/51680 · Handelsregister VR 29966 B
•
•
1) auf HL7 (Version 3) Basis einen ersten Level (ein Datensatz ohne 1:n Relationen, z.B.
keine Betreuer) für die Patientendaten erstellen => den unter eine FINSOZ-Zertifizierung
stellen
- als Abbildung einfacher Use Cases wie „neuer Patient => informiere anderes System“
Erarbeitung einer ersten Definition durch Ristok/Kahlert/Ripke/Janik - Gruppe
organisiert sich selbst
HL7 Bedingungen prüfen durch Wolff
er bietet auch an, kleinere Aufgaben in Projektform durch Studenten bearbeiten zu
lassen
2) Level 2: diese für die Rollen des Patienten weiter ausbauen (1:n Relationen mit
einbauen)
- immer auf Basis von Use Cases
3) Definition von Uses Cases für die Prozesse mit Datenaustausch
- Definition von Uses Cases für die Prozesse zwischen den Systemen
4) Erstellung einer Social Document Architecture (SDA)
nächster Termin ab Mitte September, ggf. auch schon früher
neuer Name der UAG "Personendaten"
FINSOZ e.V. · Fachverband Informationstechnologie in Sozialwirtschaft und Sozialverwaltung · Vorstandsvorsitzender Frank Nelles
Bankverbindung Kto. 1168600 BLZ 100 205 00 · Bank für Sozialwirtschaft · St.-Nr. 27/653/51680 · Handelsregister VR 29966 B