Profilierung Pilot. Sterbedatenabgleich

41 views
Skip to first unread message

Leonid Potap

unread,
Aug 23, 2012, 11:42:29 AM8/23/12
to extra-s...@googlegroups.com

Hallo Florian,

ich habe einen Vorschlag für die Profilierung der Sterbedatenabgleich vorbereitet. Analog zu den bestehenden Profildateien habe ich für das Versand der fachlichen Daten und abholen des Verarbeitungsergebnisse habe ich 2 Profile erstellt.

Bei dem Versand der Daten würde ich den Contact Plugin einsetzen. Was passiert, wenn ich eine E-Mail Adresse mit dem Contact Plugin liefere?

Schau bitte auch in die Profile, ob die syntaktisch und inhaltlich korrekt erstellt sind.

Wie geht man bei der 3 Phase (Bestätigung der erfolgreich abgeholten Rückmeldungen). Ich gehe davon aus, dass hier kein Profile nötig.

Vielen Dank und viele Grüße

Leonid

sterbedaten-phase1-fachdatensenden-profil.xml
sterbedaten-phase2-ergebnisabholen-profil.xml

Leonid Potap

unread,
Aug 30, 2012, 8:45:09 AM8/30/12
to extra-s...@googlegroups.com

Hallo Florian,

wir sind in der Implementierung weiter gegangen und noch mehr Punkte gefunden, die vereinbart werden sollten. Ich füge alle Punkte zusammen mit Vorschlägen zusammen. Am besten korrigiert Du mich, wenn bessere/andere Lösungen gibt.

1. Datenübertragung in der Phase 1 (Senden der fachlichen Daten an einen eXTra-Server).

a) Wie werden die Daten versendet?

Die Nutzdaten versenden wir in dem Feld xcpt:CharSequence.

b) Wie bekommen wir den Acknowledge und Response id.

Da wir nur einen Datensatz pro Transport versenden erwarten wir  ResponseId ist in dem Feld TransportHeader.ResponseDetails.Responseid

c) Wann ist der Versand erfolgreich?

Offen

d) Wo werden ggf. die Fehlermeldungen ausgegeben?

Sollte Transport nicht erfolgen werden die Fehlermeldungen in dem Feld TransportHeader.ResponseDetails.Report.Flag ausgegeben

2. Datenübertragung in der Phase 2 (Sender fordert Verarbeitungsergebnis des Fachverfahrens an)

            a) Wie werden die Daten abgefragt.

Anfrage nach Ergebnissen erfolgt mit den vorher übermittelten ResponseId’s.

b) In welchem Feld werden die Abfragedaten verpackt?

Die Abgefragte RepsponsId wird in dem Feld TransportBody.Data.CharSequence übertregen

b)Können in einem Transport mehrere Ergebnisse abgefragt werden?

Ein Ergebnis pro Anfrage

c)In welchem Feld werden die Ergebnisse geliefert?

Antwort wird in TransportBody.Data.CharSequence eingepackt.

3.) Bestätigung der erfolgreich abgeholten Rückmeldungen

            Offen


Viele Grüße

Leonid

Florian Stratil

unread,
Sep 7, 2012, 6:12:06 AM9/7/12
to extra-s...@googlegroups.com
Hallo

Leider erst jetzt die Antwort, da wir uns intern erst noch Abstimmen mussten, was auf Grund der Urlaubszeit gerade etwas schwierig ist.

Ich glaube, es hat auch noch ein paar Missverständnisse gegeben:

Aus unserer Sicht wäre der erste Schritt, dass wir eine Server-Application aufsetzen, welche die Sterbedaten, die wir bekommen, bereit stellt.

Schritt 1 wäre also nicht "Senden der Fachdaten" sondern bereits die Anfrage nach den Daten bei uns. Über Procedure und Datatype wäre schon eindeutig eingegrenzt, um welche Art Request es sich handelt.

Danach würde von unserer Seite die Response aufgebaut werden. Ich würde die Einzelsendungen in Packages ablegen, in deren Package-Header die ResponseID/TicketID von uns liegt, welche dann auch für die Bestätigung genutzt werden kann.
Die Nutzdaten selber würde ich, auch wenn es am Ende feste Datensätze sind, nicht in einer CharSequence ausliefern, sondern eine Base64-Char-Sequence verwenden.
Somit wären gleich zwei Fliegen mit einer Klappe geschlagen:
1. Probleme beim parsen durch Sonderzeichen oder ungewollte Zeichen würden entfallen, da der Inhalt Base64 kodiert ist.
2. Sollte sich aus Datenschutzgründen ergeben dass die Datensätze zum Versand doch verschlüsselt werden müssen, dann muss der Container nicht mehr geändert werden.

Die Übertragung der Daten sollte über das DOI-Netz mittels https geschehen. Die Nutzdaten selber sollten dabei dann unverschlüsselt verschickt werden können. Die Authentifizierung gegenüber unserer Server-Application sollte mittels Client-Zertifikat geschehen.

Die Empfangsbestätigung geschieht dann über die ResponseID, welche in den Headern der einzelnen Packages zu finden ist.

Soweit wäre von unserer Seite erstmal die Planung des Vorgehens.

Leonid Potap

unread,
Sep 7, 2012, 9:02:39 AM9/7/12
to extra-s...@googlegroups.com
Hallo Florian,

prinzipiel ist das Vorgehen mir klar. Wäre es möglich die erwarteten Extra-Response und Extra-Request mit paar Testdaten vorzubereiten und uns zur Verfügung zu stellen?

Damit ist es noch einfacher Spezifikation abzustimmen.

Viele Grüße

Leonid

Florian Stratil

unread,
Sep 11, 2012, 7:08:58 AM9/11/12
to extra-s...@googlegroups.com, potap.ren...@googlemail.com
Auf Grund der Urlaubszeit bei uns ist das Fachmodul bei uns noch in der Implementierungsphase.
Ich hoffe, dass wir da in Kürze eine testfähige Version haben.

Dr. Lofi Dewanto

unread,
Sep 25, 2012, 9:19:44 AM9/25/12
to extra-s...@googlegroups.com
Hallo Leonid,

ich habe mit Florian über den Prozess des Datenaustausches Sterbedaten Ausland unterhalten. Es ist wie wir geplant haben, d.h. mit drei Phasen genauso wie hier beschrieben ist:

Der Florian fragt beim DSRV-Betrieb nach, da der Sterbedatenaustausch Ausland zwischen DSRV und DPRS bereits vorhanden ist, und dieser Mechanismus darf nicht geändert werden. Der Florian informiert uns sobald er mehr davon weiß.

Viele Grüße
Lofi

Am Donnerstag, 23. August 2012 17:42:29 UTC+2 schrieb Leonid Potap:
Reply all
Reply to author
Forward
0 new messages