Anleitung :: Daten einer Applikation in einen anderen Fall verschieben - Optinomic/apps GitHub Wiki

image

Anleitung :: Daten einer Applikation in einen anderen Fall verschieben

Diese Anleitung richtet sich ausschliesslich an Optinomic Admins.

Hintergrund

Nach einer Datenmigration V1 => V2 kann es vorkommen, dass Daten fälschlicherweise einem falschen Fall zugeordnet wurden. Dies ist historisch - durch einen V1 Bug - bedingt.

Schritt für Schritt Anleitung

1. Alte | PUM-ID (patient_uses_module) | Auslesen

  • Entsprechende Patient-ID auslesen. Diese Information steckt innerhalb der URL - z.Bsp. http://optinomic.cust.local/api/#/patient/2279/
    => 2279
  • App identifier auslesen, welche die falschen Daten "trägt". Diese Information steckt ebenfalls innerhalb der URL - z.Bsp. http://optinomic.cust.local/api/#/patient/2279/stay/1172/app/ch.suedhang.apps.actinfo_aus.production
    => ch.suedhang.apps.actinfo_aus.production
  • Applikation :: SQL-Toolbox starten - z.Bsp. http://optinomic.cust.local/api/#/admin/tools/sql
  • Folgenden SQL ausführen - Empfehlung Einstellungen: JSON | Screen:
SELECT id FROM patient_uses_module 
WHERE patient = '2279' 
AND module = 'ch.suedhang.apps.actinfo_aus.production';

  • Falls nur eine ID zurückgegeben wird - wunderbar: ID notieren!
    => 13779 (alt)

  • Falls mehrere ID's (patient_uses_module) zurückgegeben werden muss die korrekte ID ermittelt werden.
    => Starten Sie folgenden SQL Code & notieren Sie die ID, welche stay:1172 (gemäss 2. Schritt) enthält.

SELECT * FROM patient_uses_module 
WHERE patient = '2279' 
AND module = 'ch.suedhang.apps.actinfo_aus.production';

2. App bei korrektem Fall aktivieren.

  • Falls der Fall bereits "archiviert" ist (zwei graue Haken):
    Floating Action Button => (Bleistift-Icon) Bearbeiten: Behandlung => Under der Sektion Behandlungsphase den Button Archivierung aufheben ausführen. Ein "geöffnetes Schloss" zeigt nun an, dass dieser Fall nicht mehr archiviert ist.
  • Wechseln Sie nun in den korrekten Fall und aktivieren dort die entsprechende App.

3. Neue | PUM-ID (patient_uses_module) | Auslesen

  • Führen Sie erneut folgenden SQL Code aus und notieren Sie sich die neue ID:
SELECT id FROM patient_uses_module 
WHERE patient = '2279' 
AND module = 'ch.suedhang.apps.actinfo_aus.production';

=> 13985 (neu)

4. Event-IDs erkennen, welche in den korrekten Fall verschoben werden sollen

  • Führen Sie folgenden SQL aus. Alle events mit done: EventStatusDone sind interessant, da nur diesen Daten zugeordnet sind!
SELECT * from event 
WHERE patient_uses_module_id = 13779
  • ID's rausschreiben: 13353

5. Events mit der neu aktivierten App verknüpfen

Für alle in 4. ermittelten Event-IDs wiederholen!

  • Aktuelle Daten dieses Events prüfen:
SELECT * from event WHERE id = 13353

  • Die patient_uses_module_id dieses Events sollte nun wie in Schritt 1 ermittelt 13779 also (alt) sein.

  • Ermittelten Event der neu aktivierten App zuordnen! Vorsicht - Konzentration bei: Hinweis: 13985 gemäss 3. Neue PUM-ID ; id 13353 ist die Event-ID welche "umgezogen" werden soll:

UPDATE event SET patient_uses_module_id = 13985 WHERE id = 13353

=> Die SQL-Toolbox meldet nach diesem Ausführen ein Error. Update liefert keine Daten zurück - entsprechend weiss die SQL-Toolbox nichts damit anzufangen. Anyway: Fehler kann ignoriert werden. Um zu prüfen ob der UPDATE geklappt hat nochmals folgenden SQL ausführen und prüfen ob nun die patient_uses_module_id dieses Events wie in Schritt 3 ermittelt 13985 (neu) ist:

SELECT * from event WHERE id = 13353
  • Falls dieser Prozess geklappt hat, sind die Daten erfolgreich auf den neuen Fall verschoben worden.

6. (ev) Fall wieder "archivieren" & prüfen.

  • Selektieren Sie den Fall. Floating Action Button => (Bleistift-Icon) Bearbeiten: Behandlung => Under der Sektion Behandlungsphase den Button AUTO ausführen. Fall ist wieder archiviert.
  • Prüfen ob Daten in der neu aktivierten App vorhanden sind.

In Short:

First, a quick reminder: a survey response is linked to an event which is linked to a "patient uses module" which might be linked to a stay. ("Might be" because some module can be activated for a patient regardless of a specific stay.)

Now here is how they can proceed. Once they've identified some survey responses which should be assigned to another stay, they should find the PUM ID of the module with the correct stay. With this information, they can then change the events to point to the correct PUM instead.

-- To find the PUM with the correct stay
SELECT * FROM patient_uses_module WHERE patient_id = 2313 AND module = 'ch.suedhang.apps.bscl_anq.production';
-- If they want to move the events from one PUM to another, then it's simply
UPDATE events SET patient_uses_module_id = 123456 WHERE patient_uses_module_id = 789789;
-- If they want to filter on some survey responses in particular
UPDATE events SET patient_uses_module_id = 123456 WHERE id IN (SELECT event.id FROM event LEFT JOIN survey_responses AS sr ON sr.event_id = event.id WHERE sr.something = 'some value');