[Joa]

Hallo zusammen,

so, ich habe aus gegebenem Anlass mal wieder SiDiary aus der Versenkung geholt und war sehr erfreut (nun auch schon mal) zu registrieren, dass Alf zwischenzeitlich eine erste Lösung zum Handling von CGM-Daten eingebaut hat, die ich auch ausgesprochen gelungen und pragmatisch sinnvoll finde. 

Ein Problem ergibt sich allerdings, wenn ich die Druckvorlagen benutzen möchte, um das Protokoll zu Papier zu bringen.

Die CGM-Daten für den BZ(BG) werden in Sidary, wenn entsprechend eingestellt, als eigenes Ereignis (Event) behandelt.

Am Beispiel des Novo-Protokolls als Druckvorlage führt das dazu, dass im Protokoll massenweise leere Spalten zwischen den Spalten mit Daten erscheinen, so dass die Spalten für 24 Stunden sich über etwa 6 Seiten hinquälen.

Kann ich das mit einfachen Mitteln selbst abstellen, oder müssten da entweder in den Vorlagen oder in SD selber entsprechende Manipulationen/Änderungen/Optionseinfügungen erfolgen? 

Danke vorab für Hilfestellungen.   

Gruß
Joa

[Joa]

Nachtrag:

Also beim Novo-Protokoll Ausdruck wird wohl für jeden vorhandenen Event eine Zeitspalte eingefügt. Bei irgendwelchen anderen Ausdrucken auch noch.

Ausdrucke, die das Protokoll auf 24 Spalten  - je Stunde eine Spalte - beschränken, zeigen den Effekt (natürlich) nicht.

Dazu dann noch die Frage, wie sich die Grafik des Verlaufs der CGM-Daten in einen Ausdruck einfügen lässt? 

Viele Grüße
Joa

[Alf]

Hallo Joa,

ich denke das Aufblähen der Ausdrucke nach dem CGMS-Import liegt weniger an den als CGMS-Datentyp importierten Werten aus Deinem Navigator, sondern, dass im Rahmen dieses Imports auch diverse "Zeitslot"-Infos impotiertiert wurden (die ganzen T-Events, die auch im Tagebuch zu sehen sind), die Abbott CoPilot ebenfalls bereitstellt.

Die CGMS-Daten erscheinen ja nicht als Event, sondern als zusätzlicher Datentyp, so dass man ihn im Tagebuch auch ausgeblendet lassen kann.

Dafür spricht auch, dass das Novo-Tagebuch-Template so explodiert und die 24H-Templates nicht: Die 24H-Templates haben nämlich keine Zeile für die Ereignisse...

D.h. Wenn Du die Novo-Tagebuchvorlage präferieren würdest, könntest Du dort die Ereignis-Zeile im Template herauslöschen oder aber nat. auch grundsätzlich die Ereignisse beim Import aus Copilot "abwählen", so dass die gar nicht ins Tagebuch kopiert werden (nach dem CoPilot-Import in SiDiary einfach die untere Option vor der Übernahme ins Tagebuch nehmen und dann dort die Ereignis-Kategorie abwählen).

Wegen des Ausdrucks für die UDT-Daten: Da kannst Du aktuell nur den Direktdruck aus der Statistikmaske verwenden. Den Platzhalter für eine Verlaufskurve analog zu den Labordaten müssen wir als Template noch abbilden...

Viele Grüße, Alf.

[Joa]

Hallo Alf,

ich wähle grundsätzlich: "als GGMS-Daten importieren". Was bislang auch funzte.

ich denke das Aufblähen der Ausdrucke nach dem CGMS-Import liegt weniger an den als CGMS-Datentyp importierten Werten aus Deinem Navigator, sondern, dass im Rahmen dieses Imports auch diverse "Zeitslot"-Infos impotiertiert wurden (die ganzen T-Events, die auch im Tagebuch zu sehen sind), die Abbott CoPilot ebenfalls bereitstellt.

Kann ich nicht mitvollziehen. Im Tagebuch sind da keine T-Events zu sehen. Und in der Auswahl, welche Daten beim Import übernommen werden sollen ist nur 1 Event zu finden. Auch wenn der Import von Events abgewählt wird, kommt es seit heute (16.11.) dazu, dass der Import die Tagebuchansicht nur noch als Liste aufmacht, weil SD meint, dass zu viele Daten vorhanden seien.

Vermutlich das gleiche Problem wie bei der Novo-Vorlage, die ja die 10-minütigen Mittlungswerte vom Navigator importiert.

Irgendwo ist die Trennung zwischen CGM-Daten und dem Rest des Datenbestandes löchrig? 

Es scheinen die T-Events des CGM ein Hintertürchen zu finden?

Was denn möglicherweise aus der Analyse der Nov0-Templates ersichtlich wird?

Gruß
Joa

[Alf]

Hi Joa,

Irgendwo ist die Trennung zwischen CGM-Daten und dem Rest des Datenbestandes löchrig? 
Es scheinen die T-Events des CGM ein Hintertürchen zu finden?

nee, jetzt geht's grad ein bisschen durcheinander...
Die CGMS-Daten haben definitiv nichts mit den Ereignis-Daten zu tun. Das ist in der Datenbank voneinander gekapselt abgelegt.

Mach doch mal bitte die Datenliste auf und schau dort nach, was am 16.11. für Daten vorhanden sind. Grundsätzlich kann nat. auch jede andere Datenkategorie dazu führen, dass die Tagebuchansicht nicht mehr dargestellt werden kann. Da geht's ja drum, dass das Grid dann einfach nicht mehr Spalten verträgt, egal ob diese Spalten wegen vieler Daten in der CGMS-Zeile, BZ-Zeile oder sonstwoher stammen...

Ich habe eben übrigens noch schnell die Vorlage für die UDTs umgesetzt; das kommt dann mit dem nächsten Update...

Viele Grüße, Alf.

[Joa]

Naaaben (gähn) Alf,

Es scheinen die T-Events des CGM ein Hintertürchen zu finden?

nee, jetzt geht's grad ein bisschen durcheinander...
Die CGMS-Daten haben definitiv nichts mit den Ereignis-Daten zu tun. Das ist in der Datenbank voneinander gekapselt abgelegt.

[/quote]

Glaub ich wohl auch, dass es ein bisschen durcheinander ging. Entwirrt sich aber so laaangsam.

Offenbar richtet sich die SiDiary Druck- und Exportabteilung immer nach den Einstellungen des Statistikfensters?

Ist für dieses die Darstellung des CGM-Grids aktiv, bekommt jeder CGM-Datenpunkt einen T-event im gedruckten Protokoll zugeordnet, dem aber der zugehörige CGM-Wert dann nicht zugewiesen wird.

Muss man erst mal drauf kommen. 

Ich danke für die hilfreiche Anregung. 

Aber das nächste, vorgeblich siebensieglig scheinende Rätsel hat sich auch schon gezeigt. Demnächst mehr...

Gute Nacht
und
Gruß

Joa

[Alf]

Ich fürchte, das musst Du mir nochmal erklären. Habe ich schlichtweg nicht verstanden...
Wenn es diesbezüglich eine Korrelation zwischen Statistikfenster und Drucken gibt, wäre das nicht beabsichtigt und falsch...

[Joa]

Ich fürchte, das musst Du mir nochmal erklären. Habe ich schlichtweg nicht verstanden...

Also ich denke/erinnere, dass ich Drucken in die NovoStyle Vorlage aufgerufen haben.
Wenn im Statistikfenster die CGMS-Ansicht im Zusatzfenster aktiviert war, gab es im Ausdruck für jeden CGMS-Glucosewert leere Zeitspalten. Entsprechend der Wertmittlung des FSN alle 10 Minuten eine.

Bei deaktivierter CGM-Darstellung in der Statistik (Verlaufsgrafik) war alles fein.
Und das jeweils für den Druck des gleichen Zeitraums. So meine ich jedenfalls (erst mal).

Allerdings kann ich das heute nicht mehr reproduzieren kann, nur noch leere Spalten drin, es sei denn, es sind noch keine CGMS-Daten importiert, muss ich in Betracht ziehen, evtl. bei meiner vorgehenden Beobachtung diese doch mit unterschiedlichen Zeiträumen gemacht zu haben? 

Ok. Bleibt erst mal die Frage, wie die anscheinend zu Leerspalten führende Verknüpfung zum Datentyp CGMS verhindert werden kann.

Eine Frage die sich möglicherweise auch auf das Tagebuchfenster erstrecken könnte, weil dieses seit gestern bei mir nicht mehr angezeigt wird, nach dem letzten CoPilot-Import. Zu viele Daten...  Daher nur noch Listenansicht.

Wenn der Tag keine CGMS-Datensätze enthält, geht natürlich das Tagebuch auch wieder.

Zu der weiter vorher gestellten Frage nach den in der Datenliste enthaltenen Datensätzen. In der Liste tauchen die CGMS Daten immer auf.
Es sei denn ich wähle den Filter ab. Was allerdings nicht zu speichern geht.

Gruß
Joa

[Avidflyer]

Hi Joa!

Sidiary und CGMS Daten sind konträre Dinge!

Probleme entstehen nicht nur beim Ausdruck, sondern auch:

-  Sidiary importiert den Insulintyp falsch ( immer als Bolus)

-  Es ist nicht möglich, diesen zu editieren, weder Local noch bei Sidiary-online

-  Beim Import als BZ werden jeder 2. bis 3. Wert weggelassen

-  Synchronisierung mit Onlineserver bringt immer eine Fehlermeldung, Daten sind aber vollständig da.


Gruss Klaus

[Alf]

Sidiary und CGMS Daten sind konträre Dinge!

Uiuiui, na jetzt muss ich doch mal reingrätschen...!

Sidiary und CGMS Daten sind konträre Dinge!
Probleme entstehen nicht nur beim Ausdruck, sondern auch:
-  Sidiary importiert den Insulintyp falsch ( immer als Bolus)

a) Ein Bolus hat nun so gar nichts mit einem CGMS zu tun - das liefert ja schliesslich "nur" Blutzuckerdaten
b) Für einen falsch zugeordnete Insulingabe müssten wir dann erst einmal klären, aus welchem Datenbestand Du importierst (CoPilot vs. Carelink)? Und wenn es dort klemmt, melde Dich doch einfach mal bei uns am Support - das hilft manchmal wirklich: Probleme von denen wir wissen, können wir oftmals sogar beheben
c) Für den Fall, dass es sich um Copilot-Daten handelt und Du uns evtl. mal eines Deiner Datenfiles zur Verfügung stellen könntest, wäre das super, denn da hatten wir neulich schon einmal jemanden am Support, der das beim CoPilot-Import bemängelte, sich aber danach leider nicht wieder gemeldet hat...

Es ist nicht möglich, diesen zu editieren, weder Local noch bei Sidiary-online

Nur damit ich das verstehe: Du kannst bei Dir importierte Bolus-Werte nicht editieren??? Da bin ich um so mehr an den Begleitumständen interessiert, denn ich wüsste nicht einen Grund warum das nicht gehen sollte.

Beim Import als BZ werden jeder 2. bis 3. Wert weggelassen

Das ist per Design so, wenn Du das Häkchen für den Dublettencheck nicht rausnimmst, denn genau das passiert dort: Ähnliche BZ-Werte, die in rascher zeitlicher Folge kommen werden als Dubletten verworfen. Einfach den Haken rausnehmen...

-  Synchronisierung mit Onlineserver bringt immer eine Fehlermeldung, Daten sind aber vollständig da.

Kannst Du das näher spezifizieren? "Welcher Fehler"?