Diabetesinfo-Forum
SiDiary => Allgemeines => Thema gestartet von: LordBritish am August 08, 2005, 11:54
-
Ein herzliches Hallo an alle!
Immer wieder kommt das Thema Erweiterung der Pumpenunterstützung in SiDiary auf.
In einem anderen Thema, ich glaube es ging um die Temporäre Basalrate, wurde vorgeschlagen doch ein Thema zu eröffnen indem dieses diskutiert wird.
Dieses ist nun einige Zeit her und ich möchte dieses hiermit in Erinnerung rufen und diese Idee aufgreifen. :palaver:
Ich würde vorschlagen wir sammeln erstmal die gewünschten Funktionen/Erweiterungen mit evtl. einer kurzen Erläuterung wozu das ganze dienen soll und
diskutieren dann den Sinn und Zweck.
Vielleicht hat der ein oder andere bei dem vorgeschlagenen Feauture auch noch eine Idee zur Erweiterung...
Ich mache dann einfach mal den anfang und habe folgende Wünsche/Vorschläge :
Ausdruck
- Bei der Ausgabe des Diagramms zusätzlich die ID mit ausgeben um eine Zuordnung im Tagebuch zu ermöglichen.
- Beim Ausdruck nur die verwendeten Basalraten ausgeben und nicht alle gespeicherten
Handling
- Auswahlliste Pumpenfeautures individuelle Sortierungsmöglichkeit/Sortierreihenfolge um die Einträge nach Bedarf sortieren zu können und um nicht anhand von Tricks in der Bezeichnung die Sortierungsfolge erzwingen zu müssen
Pumpenereignisse und Auswertung
- Neues Ereignis „Wechsel Batteriedeckel“
- Neues Ereignis „Adapterwechsel“
- Anzeige/Warnung hinsichtlich des vom Hersteller empfohlenden Wechselintervalls z.B. „Noch 3 Batteriewechsel bis zum Austausch des Batteriedeckels“
So das war meine Liste was mir so erstmal einfallen würde, jetzt seit Ihr an der Reihe...
Lord
-
- Neues Ereignis „Wechsel Batteriedeckel“
- Neues Ereignis „Adapterwechsel“
- Anzeige/Warnung hinsichtlich des vom Hersteller empfohlenden Wechselintervalls z.B. „Noch 3 Batteriewechsel bis zum Austausch des Batteriedeckels“
(Für welche Pumpe braucht man diese Features :kratz: )
Da man sie nicht für alle braucht (für die 508 z.B. nicht) würde ich vorschlagen, daß die nur dann eingeblendet werden, wenn die entsprechende Pumpe eingestellt ist.
Zum Rest: Ack!
Ist mir noch nicht so aufgefallen, weil ich eh keine Ausdrucke mache und nur ein Basalprofil habe. Daher weiß ich auch nicht wie das aussieht (z.B. bei der Event-Auswahl), wenn da mehrere Profile drinstehen.
-
- Beim Ausdruck nur die verwendeten Basalraten ausgeben und nicht alle gespeicherten
Ich hab es gerade in den Vorlagen gesehen: kann es sein, daß du einfach nur die falsche Vorlage benutzt hast? Da sind ja zwei für Pumpis...
-
- Beim Ausdruck nur die verwendeten Basalraten ausgeben und nicht alle gespeicherten
Ich hab es gerade in den Vorlagen gesehen: kann es sein, daß du einfach nur die falsche Vorlage benutzt hast? Da sind ja zwei für Pumpis...
Im Diagramm selbst auch :gruebeln: :kratz: ...ist mir bisher noch nicht aufgefallen.
aber ich nutze eine eigene Vorlage, im Grid steht auch die ID dahinter, nur eben in der Grafik nicht und
da ich zum Jäger und Sammler der Basalraten gehöre lösche ich die alten natürlich auch nicht.
Es gibt Zeiten da habe ich im Monatsausdruck 5 oder sogar noch mehr Basalraten...
Schon alleine aus Dokumentationsgründen ~ jedes halbe Jahre kommt es zu notwendigen Bauarbeiten an den
Basalarten und dann wird auch jede bsi zur endgültigen Fassung erfasst.
Lord
-
- Neues Ereignis „Wechsel Batteriedeckel“
- Neues Ereignis „Adapterwechsel“
- Anzeige/Warnung hinsichtlich des vom Hersteller empfohlenden Wechselintervalls z.B. „Noch 3 Batteriewechsel bis zum Austausch des Batteriedeckels“
(Für welche Pumpe braucht man diese Features :kratz: )
Da man sie nicht für alle braucht (für die 508 z.B. nicht) würde ich vorschlagen, daß die nur dann eingeblendet werden, wenn die entsprechende Pumpe eingestellt ist.
Zum Rest: Ack!
Ist mir noch nicht so aufgefallen, weil ich eh keine Ausdrucke mache und nur ein Basalprofil habe. Daher weiß ich auch nicht wie das aussieht (z.B. bei der Event-Auswahl), wenn da mehrere Profile drinstehen.
Bei der Spirit, die hat einen Batteriefachdeckel und der ist auch in jeder Service Packung enthalten,
genauso die Adapter die auf die Ampulle kommen (da sind sogar 2 von drin).
Da man sowieso die Service Pakcung ordert wg. den Batterien, kann man das dann
ja auch nach Serviceintervall wie Roche es vorschlägt/vorschreibt auswechseln...
nur ist es etwas mühselig jedesmal in den alten Werten rumzusuchen und zu zählen... :zwinker:
Habe damals mal im Zusammenhang mit Luftblasen und der H-TRON gelesen...
Bei vielen Luftblasen sollte man den Adapter wechsseln, da dieser undicht geworden ist
und es daher zu vermehrten Luftblasen kommt.
Das wechseln hat halt auch was mit Wasserdichtigkeit zu tun...
Lord
-
Danke für die Erklärung.
Sinnvoll ist ein solcher Zusatzevent sicher (vor allem in Verbindung mit dem angedachten Reminder)
Aber wie gesagt: das sollte dann als pumpenspezifisches Event laufen (bisher haben wir ja "nur" unspezifische Events)
Vielleicht gibt es ähnliches ja auch bei anderen Pumpen :kratz: Was sagen die Paradigmer?
Als unspezifisch würde mir da noch (um es in diesen Thread rüberholen) das verbesserte temp-BR-Managment einfallen. Das sollte dann natürlich auch irgendwie im Ausdruck auftauchen, damit man es für die Auswertung parat hat.
-
Bisher gibts nur das Ereignis Katheterwechsel, vielleicht wäre es sinnvoll zu unterscheiden
zwischen Katheterwechsel Komplett (Katheter und Kanüle) und
Katheter/Kanülenwechsel einzeln (Nur Kanüle bzw. Nur Katheter)
vielleicht sogar noch zusätzlich die Unterscheidung zwischen Kanülenwechsel rechts/links als Optionale Angabe...
Ich habe zumindest bei mir gemerkt, das sich die Werte verbessern, wenn ich auch mal zwischendruch
den Katheter wechsel.
Lord
-
Bisher gibts nur das Ereignis Katheterwechsel, vielleicht wäre es sinnvoll zu unterscheiden
zwischen Katheterwechsel Komplett (Katheter und Kanüle) und
Katheter/Kanülenwechsel einzeln (Nur Kanüle bzw. Nur Katheter)
vielleicht sogar noch zusätzlich die Unterscheidung zwischen Kanülenwechsel rechts/links als Optionale Angabe...
Ich denke das wäre ein bißchen zuviel des Guten. Sonst müssen wir irgendwann kilometerweit scrollen um zum gewünschten Event zu gelangen. Man kann ja jetzt schon eigene Kürzel eintragen oder noch besser: man legt sich das als Textbaustein für die Bemerkungen an.
Und 'KW Links'/'KW Rechts' macht medizinisch gesehen keinen Unterschied. KW ist das Entscheidende.
(Nebenbei: der Katheter ist die Kanüle. Du meintest sicher Katheter/Schlauch)
Ich fasse das eh schon zusammen. KW ist bei mir gleichbedeutend mit Katheter- und Ampullenwechsel, während AW sich nur auf die Ampulle (=Reservoir) bezieht. (Vielleicht das mal in 'RW' ändern?)
Ich habe zumindest bei mir gemerkt, das sich die Werte verbessern, wenn ich auch mal zwischendruch
den Katheter wechsel.
Sicher. Die Kath.-Spitze wird ja mit der Zeit 'eingekapselt' (es bilden sich sogenannte Fibrillen) und dann ist die Resorption nicht mehr so gut. Für mich ist ein Ansteigen der Werte immer das Signal "Jetzt schleunigst wechseln".
-
(Nebenbei: der Katheter ist die Kanüle. Du meintest sicher Katheter/Schlauch)
:ja: war bisher immer der Meinung den Katheterschlauch würde man als Katheter bezeichnen...
Danke für die Aufklärung :)
Ich fasse das eh schon zusammen. KW ist bei mir gleichbedeutend mit Katheter- und Ampullenwechsel, während AW sich nur auf die Ampulle (=Reservoir) bezieht. (Vielleicht das mal in 'RW' ändern?)
Ich habe zumindest bei mir gemerkt, das sich die Werte verbessern, wenn ich auch mal zwischendruch
den Katheter wechsel.
Sicher. Die Kath.-Spitze wird ja mit der Zeit 'eingekapselt' (es bilden sich sogenannte Fibrillen) und dann ist die Resorption nicht mehr so gut. Für mich ist ein Ansteigen der Werte immer das Signal "Jetzt schleunigst wechseln".
Ich meinte nur den Katheterschlauch, nicht den Katheter, der wird eh alle 2 Tage gewechselt.
Wenn es Stahlkanülen sind muss es sogar jeden Tag sein. :moser:
Somit hätten wir ein Ereignis KSW (KatheterSchlauchWechsel).
Bei einem Reservoir-Wechsel hätten wir dann ein KSRW (Katheterschlauch + Reservoir Wechsel) oder aber auch ein KSKWRS
und bei nicht abkoppelbaren Katehtern hätten wir dann ein KWRW.
Und 'KW Links'/'KW Rechts' macht medizinisch gesehen keinen Unterschied. KW ist das Entscheidende.
Das war auch mehr aus Orientierungssicht anstatt aus Medizinischer Sicht.
Es steckt halt immer noch ein wenig Diabass in mir :zwinker:
ist zwar nicht mehr mein führendes System, aber für die ein oder andere Statistik/Auswertung
verwende ich es noch.
Lord
-
Ich meinte nur den Katheterschlauch, nicht den Katheter, der wird eh alle 2 Tage gewechselt.
Ja, das hab ich schon so verstanden.
Wenn es Stahlkanülen sind muss es sogar jeden Tag sein. :moser:
Ach, bei dir auch? Ich hab mal einen ausprobiert, das fühlte sich auch nach einem Tag schon entzündet an (war es aber nicht). Deswegen bleibe ich auch bei Teflon.
Somit hätten wir ein Ereignis KSW (KatheterSchlauchWechsel).
Bei einem Reservoir-Wechsel hätten wir dann ein KSRW (Katheterschlauch + Reservoir Wechsel) oder aber auch ein KSKWRS
und bei nicht abkoppelbaren Katehtern hätten wir dann ein KWRW.
...und da blickt irgendwann keiner mehr durch :daneben:
Und 'KW Links'/'KW Rechts' macht medizinisch gesehen keinen Unterschied. KW ist das Entscheidende.
Das war auch mehr aus Orientierungssicht anstatt aus Medizinischer Sicht.
Okay, aber welchen Vorteil siehst du darin?
Ich bin der Meinung SiDiary sollte Funktionen enthalten, die als Vorteil für einen Großteil der User dienen. Alles andere würde ich unter 'Nice to have' ablegen.
Wenn wir jetzt anfangen Dinge festzulegen, die keinen direkten Vorteil haben, dann fällt es irgendwann schwer jemandem zu erklären, warum wir "Bissen x-mal gekaut vor dem Runterschlucken" nicht aufnehmen wollen.
KW, A(R)W, BW macht Sinn, denn damit kann ich meinen Verbrauch dokumentieren. Insofern macht 'SW' natürlich auch Sinn (beim FlexLink (?) kann man ja auch die Schläuche seperat bekommen)
Bei den Buchstabenkombinationen bin ich skeptisch. Erstens gibt es zuviel Varianten, wenn ich bedenke daß ich alle 4 Materialien kombinieren kann. (Bis hin zu KRBSW). Zweitens passt das irgendwann nicht mehr leserlich in die Zelle (zumindest bei PPC/Phones)
Ich denke aber auch, daß man das nicht unbedingt Minutengenau dokumentieren muss, so daß ich z.B. einen Mehrfachwechsel auf verschiedene Spalten aufteilen kann. (Der gesunde Menschenverstand wird dann schon sagen, daß man nicht über den Tag verteilt gewechselt hat)
-
Ach, bei dir auch? Ich hab mal einen ausprobiert, das fühlte sich auch nach einem Tag schon entzündet an (war es aber nicht). Deswegen bleibe ich auch bei Teflon.
Die Werte sind wesentlich stabiler und besser seitdem ich auf Teflon bin :zwinker:
Ich habe die Vermutung das ich eine leichte Nickel Allergie hatte/habe,
mein Doc meinte nur damals schwer festzustellen, probieren Sie halt einfach eine Zeit die Teflonkanülen aus.
...und da blickt irgendwann keiner mehr durch :daneben:
Wieso nicht durchblicken :zwinker:, ist doch ziemlich normal nur noch mit Abkürzungen um sich zu werfen... :mauer:
wenn ich da so an meine neues Aufgabengebiet denke...
alles nur diese besch... Abkürzungen :moser:
Hast Recht macht kein Sinn die in eins zu kombinieren, wobei ich ein SW (Schlauchwechsel) immer noch für Sinnvoll halte.
Erstmal um die Werttendenz nach einem Wechsel zu erkennen und weiterhin sind die beim Rapid D und beim Flexlink einzeln zu erstehen.
Würde dann eine neue Anwendungsmöglichkeit bieten > Achtung Dein Vorrat an ... muss aufgefüllt werden.
Sicherlich gibt´s auch noch die Bemerkungsspalte, aber ich liebe es Übersichtlich.
Ich empfinde es als wesentlich angenehmer/übersichtlicher, wenn´s im Grid steht. :zwinker:
Okay, aber welchen Vorteil siehst du darin?
Ich bin der Meinung SiDiary sollte Funktionen enthalten, die als Vorteil für einen Großteil der User dienen. Alles andere würde ich unter 'Nice to have' ablegen.
Wenn wir jetzt anfangen Dinge festzulegen, die keinen direkten Vorteil haben, dann fällt es irgendwann schwer jemandem zu erklären, warum wir "Bissen x-mal gekaut vor dem Runterschlucken" nicht aufnehmen wollen.
KW, A(R)W, BW macht Sinn, denn damit kann ich meinen Verbrauch dokumentieren. Insofern macht 'SW' natürlich auch Sinn (beim FlexLink (?) kann man ja auch die Schläuche seperat bekommen)
Bei den Buchstabenkombinationen bin ich skeptisch. Erstens gibt es zuviel Varianten, wenn ich bedenke daß ich alle 4 Materialien kombinieren kann. (Bis hin zu KRBSW). Zweitens passt das irgendwann nicht mehr leserlich in die Zelle (zumindest bei PPC/Phones)
Ich denke aber auch, daß man das nicht unbedingt Minutengenau dokumentieren muss, so daß ich z.B. einen Mehrfachwechsel auf verschiedene Spalten aufteilen kann. (Der gesunde Menschenverstand wird dann schon sagen, daß man nicht über den Tag verteilt gewechselt hat)
:gruebeln: würde wirklich nur Sinn machen, wenn man den Kathter schon entfernt hat und
dieses einige Stunden vorbei ist. Ich hab´s mir so angewöhnt einmal Rechts, einmal Links, dann wieder Rechts usw.
Stichwort Abstand mind. 3 cm :zwinker:
Ich glaube das können wir so ziemlich wieder schlafen legen, macht nicht wirklich viel Sinn die Unterscheidung zw. KW l. und KW r.
Lord
-
...wobei ich ein SW (Schlauchwechsel) immer noch für Sinnvoll halte.
Ack! (Der dokumentiert ja auch wieder etwas, was auch für die KK irgendwann mal als Nachweise gelten könnte)
Würde dann eine neue Anwendungsmöglichkeit bieten > Achtung Dein Vorrat an ... muss aufgefüllt werden.
Ja, für Blinde ohne Tastgefühl (die sehen ja nicht mehr, wieviel noch in ihrem Karton ist :lachen:
Nein ernsthaft: was ist, wenn dir beim KW mal der erste runterfällt (=unsteril wird) und der zweite nicht richtig klebt, so daß du insgesamt 3 Kath. verbraten hast. Das wäre dann ja ein KKKW :zunge2:
Sicherlich gibt´s auch noch die Bemerkungsspalte, aber ich liebe es Übersichtlich.
Ich empfinde es als wesentlich angenehmer/übersichtlicher, wenn´s im Grid steht. :zwinker:
Aber da kannst du es doch eh schon reinschreiben. Warum soll man für sowas eine ellenlange Liste machen, wenn man das auch ganz einfach reinschreiben kann?
Und für die Statistik ist es höchst hyperfluid, wie oft ich den Kath. links und wie oft rechts getragen habe.
:gruebeln: würde wirklich nur Sinn machen, wenn man den Kathter schon entfernt hat und
dieses einige Stunden vorbei ist.
...und dank Alzheimer vergessen hat, wo er lag :lachen: :lachen:
-
Nein ernsthaft: was ist, wenn dir beim KW mal der erste runterfällt (=unsteril wird) und der zweite nicht richtig klebt, so daß du insgesamt 3 Kath. verbraten hast. Das wäre dann ja ein KKKW :zunge2:
Hatte ich nicht erwähnt Unterscheidung zw. rechts/links hat sich erledigt :gruebeln: :zwinker:
Ich hatte nur noch versucht eine Sinnvolle Anwendung zu finden... :zwinker:
Falls der Katheter nicht mehr kleben will, dann kommt der Onkel Lord mit OpSite IV 3000 und dann
gehts der Kanüle so richtig an den Kragen... :zwinker: :lachen:
Ja, für Blinde ohne Tastgefühl (die sehen ja nicht mehr, wieviel noch in ihrem Karton ist
Wenn die Blind sind, wie könnne die dann die Anzeige ablesen :gruebeln:
Hast Du kein Aussenlager, also ich hab eins :ja:
Aber bisher hat die Methode nachschauen auch immer gerreicht.
Schade das wir uns alleine Unterhalten, hätte doch gedacht der ein oder andere hat auch noch ein paar Ideen...
Gibt sicherlich noch das ein oder andere was nicht schlecht wäre, auch wenn es vielleicht Pumpenspezifische Dinge sind.
Wäre doch mal sinnvoll die Ideen die jeder hat mal zu diskutieren um auch mal einen neuen Blickpunkt zu
manchen Dingen zu gewinnen...
Lord
-
Schade das wir uns alleine Unterhalten, hätte doch gedacht der ein oder andere hat auch noch ein paar Ideen...
Soll ich ehrlich sein? Ich habe aufgegeben, und darauf verzichtet mit dem Rest meiner Ideen/Vorschlaege/Feedbacks weiter zu nerven. Im Datenmodell von SiDiary sind, wenn man einmal davon absieht dass diverse Felder vom Benutzer beliebig umgenutzt werden koennen, Pumpen nicht wirklich vorgesehen, und mein Ansatz was im Datenmodell beruecksichtigt werden kann wurde mit Laufgeschwindigkeit und Komplexitaet abgeschmettert.
Wenn man mit den Einschraenkungen leben kann liegt die Staerke von SiDiary im uebersichtlichen Benutzerinterface und der sehr gut geloesten Eingabe. Allerdings habe ich die in der Praxis ohnehin nicht benutzt, sondern waehrend des Testes meine Daten mittels eines Filters fuer SiDiary umformatiert und importiert.
Nachdem ich inzwischen eine Weile damit gearbeitet habe halte ich mein Datenmodell fuer flexibler. Einen ersten Ansatz dazu hatte ich ja in einem anderen Thread veroeffentlicht. So eine huebsche Software wie SiDiary habe ich mir zur Eingabe nicht gestrickt, bisher packe ich die einzelnen Eintraege recht unzeremoniell mit einem Editor in eine csv Datei. Zum weiteren Missbrauch werden sie bisher mit einem kleinen awk-Script aufbereitet und an gnuplot zum Zeichnen uebergeben.
Was ist anders? Ein Eintrag ist grundsaetzlich ein beliebiges Ereignis mit Zeitstempel und Quelle. D.h. Katheter/Schlauch/Ampullen/Dichtungsringwechsel... sind problemlos abbildbar. Quellen sind die verschiedenen Messgeraete, Pumpen, Pens, der Logbuchfuehrende, Arzt, Labor,...
Pumpenspezifische Dinge sind im Datenmodell beruecksichtigt, und spiegeln sich auch in der Graphik wieder. Wenn er im Datenmodell vorgesehen ist kann z.b. ein verlaengerter Bolus auch graphisch dargestellt werden, und auch eine Basalrate kann so mitgeplottet werden wie sie laut Pumpe abegeben worden ist, d.h. die BR-Absenkung, die jemand waehrend des Sportes eingesetzt hat, oder aber der Katheterwechsel mit laengerem Badewannenaufenthalt werden in der Graphik sichtbar. Zum Ampullenwechsel gehoert die Information welches Insulin sich ab sofort in der Pumpe befindet, zu einem Bolus die Information welches Insulin wie verabreicht wurde (Pumpe? gesplittet? iv?). Das ist erheblich weniger aufwendig als es klingt, zumal auch hier gilt dass jeder nur das protokolliert was er fuer sich selbst fuer relevant haelt.
Wie geht's weiter? Bei Lehmann/Deutsch habe ich ein Zeitmodell gefunden, das tatsaechlich eine Einordnung der protokollierten Werte im Tagesverlauf zulaesst, ohne einen "Standardtagesablauf" vorauszusetzen. Das zu implementieren braucht allerdings etwas Datumsarithmetik, und die in awk zu implementieren waere doch etwas aufwendig, Ich werde das awk script wohl durch ein perl script ersetzen.
:pappnase: Tatjana
-
Im Datenmodell von SiDiary sind, wenn man einmal davon absieht dass diverse Felder vom Benutzer beliebig umgenutzt werden koennen, Pumpen nicht wirklich vorgesehen,
:haeh:
Mir ist nicht ganz klar wie das zu verstehen ist. Ich nutze eine Pumpe und kann meine diesbezüglche Dokumentation sehr gut mit mit SiDiary erledigen. Einschränkungen muß ich mir dafür nicht auferlegen.
Zum Ampullenwechsel gehoert die Information welches Insulin sich ab sofort in der Pumpe befindet, zu einem Bolus die Information welches Insulin wie verabreicht wurde (Pumpe? gesplittet? iv?). Das ist erheblich weniger aufwendig als es klingt, zumal auch hier gilt dass jeder nur das protokolliert was er fuer sich selbst fuer relevant haelt.
Und was davon lässt sich mit SiDiary nicht dokumentieren?
-
Im Datenmodell von SiDiary sind, wenn man einmal davon absieht dass diverse Felder vom Benutzer beliebig umgenutzt werden koennen, Pumpen nicht wirklich vorgesehen,
:haeh:
Mir ist nicht ganz klar wie das zu verstehen ist. Ich nutze eine Pumpe und kann meine diesbezüglche Dokumentation sehr gut mit mit SiDiary erledigen. Einschränkungen muß ich mir dafür nicht auferlegen.
Ich kann mir schon ganz gut vorstellen was Tatjana meint... wenn ich mir die alten Postings mal stichartig ansehe.
Könnte mir vorstellen das damit zum Beispiel Dokumentation von SEA bzw. DEA gemeint ist...
> Nimm doch die Zeile Aceton die nutzt eh kaum einer oder so ähnlich kam es damals glaube ich rüber.
Ohne irgendwenn nahe treten zu wollen... Das Tatjana dann irgendwann keine Lust mehr hatte gegen so einen Strom zu schwimmen kann ich irgendwie
auch verstehen. Ist eigentlich Schade um die Ideen, da wäre mit Sicherheit die ein oder andere gute Idee noch dabei gewesen.
Vielleicht hat der ein oder andere auch lieber nichts gesagt ich finds auch gut, weil er sonst...
Vielleicht sollte man das System ändern und eher so eine Umfrage machen : Ist dieses Feauture für Dich sinnvoll Ja/Nein/Weiß nicht
Da käme man vielleicht doch eher zu einen Ergebnis und würde sehen wie sehr dieses Feature gefragt ist.
Um wieder zum Beispiel DEA/SEA zurückzukommen...
Hier hätte man dann genauso den Sinn und Zweck der Aceton Spalte diskutieren können, ich glaube das
eher der DEA öfters dokumentiert wird als Aceton. So oft misst man das nicht (wenn wärs wohl ein Zeichen von Therapie ändern!)
und bei den normalerweise wenigen Acetonmessungen könnte man für das Aceton genauso die Bemerkungsspalte nehmen.
Wenn jetzt Zeilen dazu kommen passt es nicht mehr auf den PPC Bildschirm das ist klar, doch wer nutzt schon alle Zeilen :kratz:
Bei Ausblendung der ein oder anderen Zeile würde alles wieder drauf passen.
Auch das Argument man kann es auch übertreiben mit dem Dokumentieren, ist zwar auch genau meine Meinung,
aber Tatjanas Posting hat mich doch mal dazu angeregt die andere Seite zu sehen.
Wenn ich jetzt nochmal genau drüber nachdenke ist das eine für den einen wichtig und das andere für den anderen.
Das man alle unter einen Hut bekommt ist schier unmöglich, hier wäre es vielleicht sinnvoller dann nach einem Lösungsansatz zu suchen,
wie kann man alles aufnehmen ohne das die Übersichtlichkeit (die wirklich gut an SiDiary ist) verloren geht.
Diese "Sonderfälle" sollte man dann bei Bedarf ein- bzw. ausblenden könnne. Vielleicht wäre ja auch ein zusätzlicher Reiter mit
2. Grid sinnvoll. So das man das bisherige mit den Basisdingen so beläst und ein zweites mit Spezialdokumentation einführt.
Es kommt bei den Events die Aussage die Liste ect. wird zu lang unübersichtlich... genau dann wäre es ja ein Zeichen dafür das man
hier handeln sollte. Eine Konfigurierbarkeit schaffen Reihenfolge, Ein-Ausblenden usw...
Um mal in fremden Gehegen zu wildern bei Diabass z.B. kann man bestimmen welche Events eingeblendet bzw. ausgeblendet werden...
Das ganze ist jetzt nicht Böse gemeint gewesen :knuddel: und ich möchte auch keinem zu Nahe treten. :knuddel:
So könnte ich mir das nur vorstellen wie es von dem ein oder anderen empfunden werden könnte, wenn ich mich in die Lage des/der anderen versetzen würde...
Zum Ampullenwechsel gehoert die Information welches Insulin sich ab sofort in der Pumpe befindet, zu einem Bolus die Information welches Insulin wie verabreicht wurde (Pumpe? gesplittet? iv?). Das ist erheblich weniger aufwendig als es klingt, zumal auch hier gilt dass jeder nur das protokolliert was er fuer sich selbst fuer relevant haelt.
Und was davon lässt sich mit SiDiary nicht dokumentieren?
Hier denke ich weiß ich auch was Tatjana meint, es kann immer nur das aktuelle Insulin eingetragen werden, aber nicht direkt eine
Historie geführt werden. Was ist wenn mal das Insulin geändert wird s. z.B. wechsel von Humaninsulin auf Analogon
Nicht jeder kennt die Mögklichkeit des Multipatienten Modus... und auch hier hätte man dann einen Schnitt und könnte keine
Gesamtauswertung fahren.
Weiterhin gibt es nur 2 Eingabemöglichkeiten Bolus Insulin und Basal Insulin bzw. Pumpe
Somit muss man immer auf eine Eingabemöglichkiet verzichten.
Was ist, wenn ich die Pumpe mal ein Tag ablege und Basal spritzen möchte/muss, tja dann steht man
da und kann das nicht wirklich dokumentieren da Pumpe davorsteht... und die Auswahl kommt.
Hier dann für einen Tag alles wieder in mehrer Patienten aufsplitten... nciht so sinnvoll denke ich...
zumal auch wieder schlechte Auswertung über längere Zeit.
Wie schon gesagt ist jetzt nicht böse gemeint und keiner soll sich auf den Schlips getreten fühlen.
Ich komme mit SiDiary so ganz gut zurecht wie es ist und kann mit der ein oder anderen Sache (noch) leben.
Ist halt nur Schade das gute Ideen Aufgrund unglücklicher Gegebenheiten dann nicht mehr zum Vorschein kommen.
Und das da noch Wünsche und Potential in Richtung Pumpe ist, merkt man doch an dem ein oder anderen Posting schon.
@Tatjana vielleicht überlegst Du es Dir ja nochmal und unternimmst nochmal einen Versuch, fände ich jedenfalls
schön. Vielleichst magst Du Dich ja auch mal dazu äussern was Du damals nicht so toll fandest...
Lord
-
Hallo zusammen,
ich bin bisher auch nicht so glücklich mit der DM Sofware die ich gefunden habe.
In Papierform kommt mir das Protokoll von Teupe sehr entgegen allerdings habe ich mit der aktuellen Version das Problem das ich einige Daten nicht so eintrage wie ich mir das wünsche.
Also z. B. BE und Insulin nicht in einer Tabelle anstelle der Grafik bzw. beides.
Ich mache mir auch gerade Gedanken wie ein Datenmodel aussehen müsse sollte um einige Sonderfälle abdecken zu können.
Allerdings tendiere ich nicht wie Tatjana zu awk sondern zur perl als Lösung für die Software.
Grüßle
Norbert
-
Könnte mir vorstellen das damit zum Beispiel Dokumentation von SEA bzw. DEA gemeint ist...
> Nimm doch die Zeile Aceton die nutzt eh kaum einer oder so ähnlich kam es damals glaube ich rüber.
Und der Meinung bin ich immer noch. Mir wäre es allerdings auch lieber, wenn man die dann auch umbenennen könnte. z.B. in Aceton/EA. (Dann natürlich kurz erklären daß 'EA' für Ess-Abstand steht und damit gleichermassen SEA und DEA bedient und wozu as gut ist. Steht dann eine Zahl drin (für AE mit negativem Vorzeichen) meint das die Minuten, die man gewartet hat. Und Aceton kann man dann weiterhin semiquantitativ eintragen mit +, ++ und +++
Das Tatjana dann irgendwann keine Lust mehr hatte gegen so einen Strom zu schwimmen kann ich irgendwie auch verstehen.
Ja, ich auch. Aber ebenso wie sie das Recht hat ihre Meinung zu sagen möchte ich auch das Recht haben meine zu äußern. Und ich finde eben nicht alles gut.
Meine Meinung ist lediglich meine Meinung und zählt keinesfalls mehr als ihre, deine oder die irgendeines anderen.
Wenn es um SiDiary geht habe ich lediglich ein paar Vorstellungen. Es soll einfach gehalten sein, damit jeder damit zurechtkommt (was nicht bei jeder Diabetes-Software so ist) und es soll Dinge enthalten, die für eine spätere Auswertung einen Sinn haben.
Es sollte nicht selbsttätig eine Auswertung machen, denn dazu ist die Fehlerstreuung zu hoch. Es gibt nunmal keinen standardisierten Diabetes, an dem man sich orientieren könnte. Es gibt lediglich Richtgrößen, die aber auch noch von Mensch zu Mensch unterschiedlich ausfallen können.
Vielleicht sollte man das System ändern und eher so eine Umfrage machen : Ist dieses Feauture für Dich sinnvoll Ja/Nein/Weiß nicht
Die Möglichkeit besteht ja mit diesem Forum: Grundsätzlich kann jedes Mitgleid eine beleibige Umfrage starten.
Ich fände es auch gut (sehr sogar), wenn man eine Umfrage startet, nachdem man in einer Diskussion keinen Konsenz erreicht hat. Dann hat jeder seine Argumente offengelegt und alle anderen können dann ihr Votum abgeben.
Um wieder zum Beispiel DEA/SEA zurückzukommen...
Hier hätte man dann genauso den Sinn und Zweck der Aceton Spalte diskutieren können, ich glaube das
eher der DEA öfters dokumentiert wird als Aceton. So oft misst man das nicht (wenn wärs wohl ein Zeichen von Therapie ändern!) und bei den normalerweise wenigen Acetonmessungen könnte man für das Aceton genauso die Bemerkungsspalte nehmen.
Ja, sehe ich auch so.
Auch das Argument man kann es auch übertreiben mit dem Dokumentieren, ist zwar auch genau meine Meinung, aber Tatjanas Posting hat mich doch mal dazu angeregt die andere Seite zu sehen.
Sicher. Aber auch da kann man auf die Bemerkungen verweisen. Gerade durch die Lösung Textbausteine zu definieren kann sich doch jeder das, was ihm wichtig ist dokumentieren.
Als Default-Event würde ich lieber nur die Dinge nehmen, die bei einer Vielzahl der User gefragt sind.
Vielleicht wäre ja auch ein zusätzlicher Reiter mit 2. Grid sinnvoll. So das man das bisherige mit den Basisdingen so beläst und ein zweites mit Spezialdokumentation einführt.
Ja, kann ich mir vorstellen. In manchen Dingen wäre eh schon eine Neustrukturierung der Anordnung sinnvoll. (z.B. die Buttons Im-/Export zusammenlegen)
Das ganze ist jetzt nicht Böse gemeint gewesen :knuddel: und ich möchte auch keinem zu Nahe treten. :knuddel:
Es macht mich irgendwie betroffen, daß du jetzt anscheinend das Gefühl hast deine Aussagen abmildern zu müssen.
Also nochmal in aller Deutlichkeit: ich bin hier nur der Admin, quasi der Hausverwalter. Dies ist unser aller Forum und die Meinung jedes Einzelnen ist absolut gleichwertig. Besonders Leute, die neu dazugekommen sind und vielleicht erst seit kurzem Diabetiker sind sollten sich nicht zurückhalten á la "Die anderen kennen sich damit ja besser aus", denn darum geht es nicht. Ich mag mich in Diabetesfragen gut auskennen, aber ich kann absolut nicht in die Köpfe anderer Menschen sehen und wissen, welche Vorlieben die haben.
So könnte ich mir das nur vorstellen wie es von dem ein oder anderen empfunden werden könnte, wenn ich mich in die Lage des/der anderen versetzen würde...
Hier denke ich weiß ich auch was Tatjana meint, es kann immer nur das aktuelle Insulin eingetragen werden, aber nicht direkt eine Historie geführt werden. Was ist wenn mal das Insulin geändert wird s. z.B. wechsel von Humaninsulin auf Analogon
Ebenso wie mit all den anderen Dingen, die nicht häufig vorkommen: -> Bemerkungen.
Und da wird es wirklich lanngsam Zeit, daß man in den Bemerkungen eine Volltextsuche machen kann. So würde einen der Suchstring "Insulinwechsel" schnell an den Tag führen, an dem man umgestiegen ist.
Was ist, wenn ich die Pumpe mal ein Tag ablege und Basal spritzen möchte/muss, tja dann steht man
da und kann das nicht wirklich dokumentieren da Pumpe davorsteht...
Du hast den Event 'PAb' und kannst in den Bemerkungen festlegen, welches Basal du spritzt. (Oder im Profil als zweites Basal eintragen). Die Dosis trägt man dann in die entsprechende Spalte ein, da wird sie dann auch in die Basalberechnung mit einfließen.
Und das da noch Wünsche und Potential in Richtung Pumpe ist, merkt man doch an dem ein oder anderen Posting schon.
Sicher. Und genau dafür gibt es ja dieses Forum und diesen Thread.
-
Könnte mir vorstellen das damit zum Beispiel Dokumentation von SEA bzw. DEA gemeint ist...
> Nimm doch die Zeile Aceton die nutzt eh kaum einer oder so ähnlich kam es damals glaube ich rüber.
Und der Meinung bin ich immer noch. Mir wäre es allerdings auch lieber, wenn man die dann auch umbenennen könnte. z.B. in Aceton/EA. (Dann natürlich kurz erklären daß 'EA' für Ess-Abstand steht und damit gleichermassen SEA und DEA bedient und wozu as gut ist. Steht dann eine Zahl drin (für AE mit negativem Vorzeichen) meint das die Minuten, die man gewartet hat. Und Aceton kann man dann weiterhin semiquantitativ eintragen mit +, ++ und +++
Weißt Du ich bin sogar zu einem besseren Ergebnis gekommen... die Dokumentation in der Acetonspalte des DEA/SEA ist eigentlich
nicht notwendig! Benutzt man den Key zum deaktivieren der Rundung auf 5 Minuten könnte man dann die Mahlzeit einzeln dokumentieren und hätte
somit die Möglichkeit den Abstand zu sehen und könnte diesen ggf. mit Excel errechnen. Nachteilig dabei wäre allerdings das die Angaben nicht mehr untereinander stehen und die Angaben auseinandergerissen werden.
Ich persönlich dokumentiere den SEA sowieso nicht, da ich Humalog verwende. Aufgrund schlechter Erfahrungen mit SEA/DEA
habe ich i.d.R. keinen Abstand nur bei hohen Werten halte ich einen ein und dann kann ich den immer noch in der Bemerkungsspalte dokumentieren
(so selten wie das in letzter Zeit voorkommt).
Ja, ich auch. Aber ebenso wie sie das Recht hat ihre Meinung zu sagen möchte ich auch das Recht haben meine zu äußern. Und ich finde eben nicht alles gut.
Meine Meinung ist lediglich meine Meinung und zählt keinesfalls mehr als ihre, deine oder die irgendeines anderen.
Sehe ich auch so, daher ist es eigentlich schade das Tatjana nicht genau gesagt hat was sie meinte,
sondern nur Andeutungen gemacht hat. Ich habe daraus jetzt lediglich eine Mutmassung aufgestellt.
Daher habe ich auch meine Aussage abgemildert, weil es lediglich Mutmassungen waren und ich wollte
es milde ausdrücken. Das ist auch nicht unbedingt ganz so meine Sicht, ich wollte lediglich
einen Anstoss dazu geben was Tatjana meinen könnte... und Tatjana hiermit ermutigen zu sagen was sie
sagen eigentlich sagen wollte.
Ich finde auch das jeder seine Meinung äussern sollte und keine ein höheres Gewicht hat als die andere.
Das man nicht unbedingt einer Meinung ist, ist denke ich vollkommen normal und daraus ergibt sich dann ja
bei einer vernünftigen Diskussion neue Erkentnisse.
Dann ist es etwas Schade wenn sich einer zurückzieht und nicht versucht seine Meinung etwas
näher zu bringen welchen Sinn es macht und das es evtl. für andere auch nutzbringend ist.
Wenn es um SiDiary geht habe ich lediglich ein paar Vorstellungen. Es soll einfach gehalten sein, damit jeder damit zurechtkommt (was nicht bei jeder Diabetes-Software so ist) und es soll Dinge enthalten, die für eine spätere Auswertung einen Sinn haben.
Es sollte nicht selbsttätig eine Auswertung machen, denn dazu ist die Fehlerstreuung zu hoch. Es gibt nunmal keinen standardisierten Diabetes, an dem man sich orientieren könnte. Es gibt lediglich Richtgrößen, die aber auch noch von Mensch zu Mensch unterschiedlich ausfallen können.
Dafür haben wir ja auch die gute Schnittstelle, CSV Export, Excel, Word hier kann man dann mit etwas
Kenntnis einige Dinge zusätzlich auswerten die für eimem Bedeutung haben.
Sicher. Aber auch da kann man auf die Bemerkungen verweisen. Gerade durch die Lösung Textbausteine zu definieren kann sich doch jeder das, was ihm wichtig ist dokumentieren.
Als Default-Event würde ich lieber nur die Dinge nehmen, die bei einer Vielzahl der User gefragt sind.
Hat aber auch keinen Sinn immer nur zu sagen : "Dafür gibt´s das Bemerkungsfeld"
Manches macht vielleicht doch für viele Sinn und das läßt sich bestimmt auch so implementieren das
die Einfachheit nicht leidet.
Möchte darauf hinweisen, das so manches untergehen könnte, bei einer langen Liste an Bemerkungen... :zwinker:
Lord
-
Nachteilig dabei wäre allerdings das die Angaben nicht mehr untereinander stehen und die Angaben auseinandergerissen werden.
Eben, und das würde mir gar nicht gefallen und wäre ein bißchen zu viel Aufwand (wenn ich kurz vor dem Essen nochmal protokollieren müsste)
Ich persönlich dokumentiere den SEA sowieso nicht,
Ich auch nicht. Jedenfalls nicht standardmäßig, sondern nur, wenn ich mal wieder etwas ausprobiere. Ansonsten kenne ich meine Zeiten. (15-0-15 für Humalog)
Trotzdem ist das für die Praxis sinnvoll, z.B. wenn man an einen Diabetiker denkt, der gerade ein-/umgestellt wird. Wenn der 'seinen' SEA/DEA erstmal rausgefunden hat braucht er den auch nicht mehr täglich zu dokumentieren. Da wäre es aber trotzdem gut - so ähnlich hatte Tatjana das ja auch schon mal vorgeschlagen - wenn man diese Daten dann ins Profil eintragen könnte.
Ich hätte SiDiary gerne als umfassendes DM-Managment, womit sich jeder schnell einen Überblick verschaffen kann, nach welchen Parametern derjenige eingestellt ist. Insofern wäre es sicher auch sinnvoll eine neue Regelung für die Korrekturfaktoren zu finden. Das könnte dann so ähnlich aussehen wie die Basalratenverwaltung, nur daß die Schieber eben die Korrekturregel berücksichtigen.
Es gibt noch einiges zu tun, und deswegen reden wir ja darüber.
Es sollte nicht selbsttätig eine Auswertung machen, denn dazu ist die Fehlerstreuung zu hoch. Es gibt nunmal keinen standardisierten Diabetes, an dem man sich orientieren könnte. Es gibt lediglich Richtgrößen, die aber auch noch von Mensch zu Mensch unterschiedlich ausfallen können.
Dafür haben wir ja auch die gute Schnittstelle, CSV Export, Excel, Word hier kann man dann mit etwas
Kenntnis einige Dinge zusätzlich auswerten die für eimem Bedeutung haben.
Yep. Und falls sich bei irgendeiner Export-Vorlage etwas getan hat, daß für alle sinnvoll sein kann, dann kann man das ja immer noch implementieren.
Sicher. Aber auch da kann man auf die Bemerkungen verweisen. Gerade durch die Lösung Textbausteine zu definieren kann sich doch jeder das, was ihm wichtig ist dokumentieren.
Als Default-Event würde ich lieber nur die Dinge nehmen, die bei einer Vielzahl der User gefragt sind.
Hat aber auch keinen Sinn immer nur zu sagen : "Dafür gibt´s das Bemerkungsfeld"
Manches macht vielleicht doch für viele Sinn und das läßt sich bestimmt auch so implementieren das
die Einfachheit nicht leidet.
Möchte darauf hinweisen, das so manches untergehen könnte, bei einer langen Liste an Bemerkungen... :zwinker:
Klar, wenn es für viele sinnvoll ist, dann sollte man das als Default implementieren.
Ich würde mal sagen - um einen Ansatzpunkt zu haben - daß das Bemerkungsfeld für Dinge ist, die gelegentlich mal vorkommen können. Z.B. i.v.-Korrektur.
Kommt etwas häufiger (und bei vielen) vor, dann wäre es schön, das 'clickable' zu machen.
Für solche Sachen und für die, bei denen wir keinen Konsenz erreichen haben wir hier im Forum das Werkzeug 'Umfrage'. Nutzen wir es!
-
Ich auch nicht. Jedenfalls nicht standardmäßig, sondern nur, wenn ich mal wieder etwas ausprobiere. Ansonsten kenne ich meine Zeiten. (15-0-15 für Humalog)
Bei mir kommt nur später ggf. ein Bemerkungstext längerer DEA o.ä. rein, wenn der nachfolgende Wert nicht
passt z.B. bei einer anschliesenden Hypo.
Dann ist die Bemerkungsspalte auch etwas entlastet... :zwinker:
Trotzdem ist das für die Praxis sinnvoll, z.B. wenn man an einen Diabetiker denkt, der gerade ein-/umgestellt wird. Wenn der 'seinen' SEA/DEA erstmal rausgefunden hat braucht er den auch nicht mehr täglich zu dokumentieren.
Das sollte es auch nicht bedeuten das es keinen Sinn macht diesen nicht doch mal zu dokumentieren.
Sollte nur bedeuten es gibt auch noch einen anderen Weg nach Rom ohne Verfremdung von Zeilen :zwinker:
Ich weiss ja auch nicht unbedingt vorher mein DEA, der könnte sich ja auch noch ändern
z.B. durch ein Telefonanruf o.ä. ...
Ich würde mal sagen - um einen Ansatzpunkt zu haben - daß das Bemerkungsfeld für Dinge ist, die gelegentlich mal vorkommen können. Z.B. i.v.-Korrektur.
Kommt etwas häufiger (und bei vielen) vor, dann wäre es schön, das 'clickable' zu machen.
:o :staun: Korrektur intravenös verabreicht, ich dachte das wäre nicht erlaubt und als Normalsterblicher ohne
Medizinische Ausbildung dürfte/sollte man das nicht machen...
Für solche Sachen und für die, bei denen wir keinen Konsenz erreichen haben wir hier im Forum das Werkzeug 'Umfrage'. Nutzen wir es!
Wobei ich dann bei einer kleinen Zusatzfrage wäre...
Kann man mehrer Umfragen in einem Thread zusammenfassen, weil sie z.B. thematisch zusammenpassen :kratz:
Lord
-
:o :staun: Korrektur intravenös verabreicht, ich dachte das wäre nicht erlaubt und als Normalsterblicher ohne
Medizinische Ausbildung dürfte/sollte man das nicht machen...
Sagen wir mal so: sie ist nur selten nötig. In der Regel korrigiere ich immer s.c.
Aber in einer guten Intensivschulung bekommt man auch das beigebracht.
Wobei ich dann bei einer kleinen Zusatzfrage wäre...
Kann man mehrer Umfragen in einem Thread zusammenfassen, weil sie z.B. thematisch zusammenpassen :kratz:
Sollte eigentlich möglich sein.
-
Sagen wir mal so: sie ist nur selten nötig. In der Regel korrigiere ich immer s.c.
Aber in einer guten Intensivschulung bekommt man auch das beigebracht.
:gruebeln: naja bei mir gab´s auch keine "richtige" Schulung, mehr Praxisbezogen und nicht vorher soviel/nur Theorie.
Hat auch gut geklappt, da ich mit ICT und Humalog gut umgehen konnte, war es auch nicht notwendig.
Die Bedienung und das Handling der Pumpe und das legen der Katheter war durch den Vertreter abgedeckt.
Ich fand´s auch gut so wie es war, nicht lange Fackeln sondern Handeln
Wenn ich mich mal für was entschieden habe, dann sofort in die Tat umsetzen und dann auch ganz oder gar nicht.
(meistens jedenfalls)
Wann würde man i.v. korrigieren - bei einer Ketoazidose :kratz:
Lord
-
Bei einer Ketoazidose hilft i.v. wegen der kurzen Halbwertszeit des Insulins im grossen Kreislauf relativ wenig, da ist es wirkungsvoller sich die relativ grossen Insulinmengen gesplittet zu verpassen damit sie schneller kommen.
i.v. wird dann interessant, wenn neben dem schnellen Wirkungseintritt die kurze Halbwertszeit von Vorteil ist. Hinzu kommt , dass wegen des schnellen Abbaus die Insulinmenge nicht komplett in die Insulinbilanz eingeht, d.h. anders als das s.c verabreichte Korrekturinsulin nicht an der down-Regulation mitdreht. Ich nenne i.v. daher gerne die "Rettung der Resistenten" und setze es da ein, wo eine subcutane Korrektur groessere Mengen Insulin einsetzen wuerde oder zu lange dauern wuerde.
Eine normale pp-Korrektur mache ich auch mit der Pumpe, oder wenn es etwas schneller gehen soll, dem Humalog Pen. Anders bei pp-Katastrophen - wenn die nach 3 Stunden erst bemerkt werden ist i.v oft die einzige Moeglichkeit den der Wert noch innerhlab der 4 Stunden, die die Glykolisierung braucht um sich dauerhaft zu binden, wieder runterzubekommen. Sehr angenehm ist auch, dass eine i.v. Korrektur wunderschoen passend im Zielbereich ankommt, ohne in einer Hypo zu enden. Das ist vor allem spaetabends interessant, wenn ein hoher pp-Wert erst vor dem Schlafengehen bemerkt wird. Eine s.c. Korrektur wuerde in solchen Faellen laenger dauern, und, wenn ich dann auch noch unsicher bin ob die Menge reicht oder in einer Hypo endet ist die Nacht gelaufen. Mit i.v. ist die Wirkung in einer Stunde vorbei und der BZ im Normalbereich. Damit kann ich dann, wenn ich die Wirkung abwarten will nach einer Stunde statt nach 3 (Analogon) oder 4 (Normalinsulin) schlafen gehen. Die Nacht ist gerettet :)
Wenn ich mir sicher bin i.v. getroffen zu haben kann ich auch gleich schlafen gehen.
Zur Haeufigkeit: Katastrophen kommen bei mir gegenwaertig so etwa alle Monate einmal vor.
Beispiel: Am 18.7. habe ich nach einem Katheterwechsel bei dem die Pumpe fuer ca. eine Stunde abgelegt war das fehlende Basalinsulin nicht nachgegeben, da ich mit 60 relativ niedrig lag und dachte dass, da die Basalluecke noch im Wirkbereich des Fruehstuecksbolus lag und anschliessend gleich das Mittagessen kommen sollte, das mit abgedeckt sei. Das Mittagessen war ein Nudelgratin mit geschaetzten 4 BE, dem habe ich 1 IE sofort und 3 IE ueber die naechsten 4 Stunden verpasst.
1 IE sofort war nun aber zu wenig, zumal da noch eine Basalluecke zu fuellen war, und der frisch gelegte Katheter ja auch erst noch seinen Arbeitsdruck erreichen musste. Gepasst haetten vermutlich 3 IE sofort, und 2 verzoegert.
So jedoch ergab das eine bilderbuchmaessige pp-Explosion:
(http://orbit.in-berlin.de/examples/iv/iv-week.jpg)
Die Katastrophe zeichnete sich bereits um 14:19 mit einem pp von 274 ab. Da ich noch einkaufen gehen wollte und der verlaengerte Bolus noch lief habe ich 2 IE (berechnet waeren 2.75 notwendig gewesen, da war aber der noch laufende verlaengerte nicht beruecksichtigt) zur Korrektur gegeben. Wieder zu Hause hatte ich um 16:09 305 :kreisch: gemessen.
Mit der Basalluecke hatte sich offenbar eine fiese Resistenz eingeschlichen, in der meine 2 IE Korrekturbolus einfach so verpufft sind. Jetzt hatte ich die Wahl daran sc herumzukorrigieren - 3.5 IE fuer den Anfang, und dann sehen was herauskommt, oder gleich 50% mehr wegen des Resistenzverdachtes? Waehrend ich dann noch abwarten wuerde was dabei herauskommt waeren die 4 Stunden in denen die Glykolisierung noch nicht einzementiert ist jedenfalls vorbei, und der Peak wuerde sich wunderbar im HbA1c manifestieren. Ich habe das dann lieber i.v. korrigiert. Damit waren die Werte innerhalb einer halben Stunde im Normalbereich. 17:48 hatte ich dann der halben BE Milch zum Kaffe eine halbe IE Insulin spendiert - die waere wahrscheinlich ueber die noch offenen Transporter nach der i.v. abgedeckt gewesen denn ich bin in der Folge etwas tiefer (58) gerutscht.
(http://orbit.in-berlin.de/examples/iv/iv-3day.jpg)
Die Graphik ist uebrigens mit meinem kleinen awk script und gnuplot erstellt. Die Summe der Basalrate unten ist geschummelt, die korrekte Summenbildung mache ich wenn ich das auf perl umgestellt habe. Die BR ist noch einmal nach oben gespiegelt, da ich die Bolusgaben, die mit der Pumpe erfolgt sind, dort flaechentreu mit hineinzeichnen moechte, auch das wird erst mit dem Perl script geschehen, ist aber ein Beiepiel dafuer was machbar ist, wenn das Datenmodell das zulaesst. Die violette Linie stellt die morgentlichen Nuechternwerte beim Aufstehen dar, zusammen mit der Summe der Gesamtinsulinmenge (IGS) als Indikator fuer den aktuellen Stand der up/down Regulation.
-
Hallo Tatjana,
Bei einer Ketoazidose hilft i.v. wegen der kurzen Halbwertszeit des Insulins im grossen Kreislauf relativ wenig, da ist es wirkungsvoller sich die relativ grossen Insulinmengen gesplittet zu verpassen damit sie schneller kommen.
Das heist dann häufiger i.V. korrigieren. Ist zwar kein Vergnügen aber sicher gangbar. Schlaffen darf man ja in der Ketoazidose sowie so nicht mehr.
Die Graphik ist uebrigens mit meinem kleinen awk script und gnuplot erstellt. Die Summe der Basalrate unten ist geschummelt, die korrekte Summenbildung mache ich wenn ich das auf perl umgestellt habe. Die BR ist noch einmal nach oben gespiegelt, da ich die Bolusgaben, die mit der Pumpe erfolgt sind, dort flaechentreu mit hineinzeichnen moechte, auch das wird erst mit dem Perl script geschehen, ist aber ein Beiepiel dafuer was machbar ist, wenn das Datenmodell das zulaesst. Die violette Linie stellt die morgentlichen Nuechternwerte beim Aufstehen dar, zusammen mit der Summe der Gesamtinsulinmenge (IGS) als Indikator fuer den aktuellen Stand der up/down Regulation.
Wenn Du noch am modelieren des Datenmodels bist biete ich an mich daran zu beteiligen. Wenn Du das willst.
Zur Not Programiere ich auch etwas in Perl. Ich bin gerade auch dabei mir Gedanken über ein Datenmodel zu machen wobei der Schwerpunkt bei Pumpentherapie liegt.
Es ist nach meinem Verständnis gar nich so einfach die Paramter aufzuschreiben die Meßwerte bzw. andere Informationen eindeutig auswertbar machen.
z. B. habe ich für einen Blutzuckerwert folgende Daten im Kopf die man speichern sollte.
Bluztuckerwert, Einheit, Tageszeit, Absolute Zeit (z. B. unix Zeit Stamp), Biorythmuszeit (schließlich ist die ja wichtig), eindeutiger Identifier für den BZ Wert (z.B. md5,sha, sha-160 Wert der vorigen Werte und Messgerätyp und Messgerätseriernnummer) damit man zwischen verschiedenen Geräten bzw. Programmen problemlos sync. machen kann.
Zusätlich fällen mir als Punkte ohne Anspruch auf Vollständigkeit noch ein: Bludruckwert, Hba1c, Einschlafzeit (Biorythmus reset :-D), Frauenspezifisches, Basalrate, Faktoren inkl. Faktorenberechnung über Basalrate für die Biorthmuszeit, ......
Grüßle
Norbert
-
Hallo Tatjana,
schön, dass es Dich noch gibt. ;-)
Bei einer Ketoazidose hilft i.v. wegen der kurzen Halbwertszeit des Insulins im grossen Kreislauf relativ
wenig, da ist es wirkungsvoller sich die relativ grossen Insulinmengen gesplittet zu verpassen damit sie schneller kommen.
i.v. wird dann interessant, wenn neben dem schnellen Wirkungseintritt die kurze Halbwertszeit von Vorteil ist.
Also ich mach das grade bei einer richtigen Ketoazidose (Keton ++ oder +++), eigentlich ganz gerne iv, wenn ich es
etwas eiliger habe, wieder fit zu werden.
Das braucht dann 2 bis 3 Injektionen von etwa 10 IE in 15 Minutenabstand. Die erste Injektion eher mit
15 IE. Parallel dazu gebe ich am Anfang eine gemäßigte A-Korrekturdosis sc.
Die erste iv Dosis zeigt natürlich kaum Wirkung, während die zweite i. d. R. schon eine deutliche BZ-Senkung
bringt. So ab 200 mg/dl macht das dann der Rest der sc Dosis und es geht mit Schema B weiter.
Hat den Vorteil, das ich nach einer Stunde wieder ziemlich voll handlungsfähig bin.
Grafik
Sehr schöne Visualisierung die Du da gestrickt hast. :ja:
Anerkennung!
Hast Du schon was von der Tageszeitmodellierung in das Datenmodell eingebaut?
Gruß
Joa
-
Vielen Dank für die Erläuterungen, werde das ganze mal bei meinem nächsten Quartalscheck bei
meinem Doc ansprechen.
Lord
-
Hallo Norbert,
Wenn Du noch am modelieren des Datenmodels bist biete ich an mich daran zu beteiligen. Wenn Du das willst.
Zur Not Programiere ich auch etwas in Perl. Ich bin gerade auch dabei mir Gedanken über ein Datenmodel zu machen wobei der Schwerpunkt bei Pumpentherapie liegt.
Es ist nach meinem Verständnis gar nich so einfach die Paramter aufzuschreiben die Meßwerte bzw. andere Informationen eindeutig auswertbar machen.
Gerne - lass uns das am besten in einem separaten Thread oder per Mail diskutieren. -hier nur kurz als Antwort auf die von Dir angesprochenen Punkte:
Die Einschlafzeit ist mit drin - der Blaue Balken oben ueber dem BZ-Graph beginnt zum Einschlafzeitpunkt (E) und hoert mit dem Aufstehen auf ;) Das Zeitmodell nach Lehmann/Deutsch ist nicht am Tagesablauf sondern am circadianen Rhytmus orientiert (ist das das, was Du "Biorhytmus" nennst?), damit ist es auch fuer Schichtarbeiter, Informatiker und andere Nachteulen brauchbar. "Frauenspezifisches" ist momentan noch nicht komplett ausmodelliert - bisher nur als Buchstabe ueber dem Graph, so wie die Katheter, Ampullenwechsel, etc. Da laesst sich mehr machen, zumal bedingt durch entsprechende Verhuetungstaktiken viele Frauen darueber sowieso ein Protokoll fuehren (Basaltemperatur, Eisprung, Menstruation, zyklussteuernde Medikamente (Pille)).
Blutzuckerwert: entweder in mmg/dl oder mmol, wobei beide auch gemischt benutzt werden koennen (z.b. wenn ein Ersatzgeraet oder eine Messung durch jemand anders in der jeweils anderen Einheit daherkommen). Das Geraet ist selbstverstaendlich eindeutig identifiziert - warum Du einen Hash ueber die vorhergehenden Werte vorsehen wuerdest habe ich noch nicht verstanden?
Viele Gruesse, Tatjana
PS: ich sehe das Datenmodell nicht beschraenkt auf Pumpentherapie. Basalinjektionen (oder Mischungen) sind explizit vorgesehen, von meiner ersten Idee ein Feld fuer Basalrate und Basalinjektionen parallel zu benutzen bin ich jedoch wieder abgekommen, da das dann das SiDiary-Problem haette: durch mangelnde/fehlerhafte Ausdifferenzierung im Datenmodell kann im nachhinein nicht mehr festgestellt werden welcher Zustand gerade gueltig war. Das Kommentarfeld ist nicht der Platz um Luecken des Datenmodells auszugleichen. Ein Wechsel zwischen BR und Basalinjektionen ist auch fuer Pumpentraeger jederzeit vorstellbar, und auch eine Umstellung von ICT auf Pumpe sollte mit allen Faktoren sauber dokumentierbar sein. Wenn das nur aus einem Volltext-Tagebuch(Kommentaren) ablesbar ist hat die Software in meinen Augen versagt, zumal gerade diese Umstellungszeitraeume eine erheblich erhoehte Motivation das auch zu dokumentieren mit sich bringen. Was ohne Nachteile realisierbar ist, ist die Basalinjektion (im Datenmodell, nicht unbedingt auch in der Dateneingabe!) wie Bolusinjektionen zu behandeln. Dies setzt nur voraus, dass fuer jede Insulingabe die Insulinsorte mitgefuehrt wird. Dies ist zur Dokumentation von Therapieaenderungen ohnehin notwendig. Wenn das geschieht laesst sich aus Sorte und Menge auch ein (modellhaftes) Wirkprofil abbilden, so dass eine kontinuierliche graphische Darstellung des (theoretisch!) gerade wirkenden Insulins moeglich wird. Die Realitaet wird davon immer abweichen, ich halte eine solche Darstellung jedoch fuer trotzdem hilfreich. Fuer den Benutzer ist der Aufwand gleich...
-
Hallo Joa,
Danke :)
Die Zeitslots nach Lehmann/Deutsch sind im Datenmodell in zwei Feldern drin: ein "Timestamp", der manuell eingetragen wird ((Aufstehen), Fruehstueck, Mittagessen, Abendessen, Einschlafen), und ein Feld fuer die 13 "Timeslots", die daraus abgeleitet werden. Mit dem awk script fuehre ich die Berechnung der slots noch nicht durch, da die preprandialen slots sich jeweils aus dem Zeitpunkt der Mahlzeit ergeben, und damit eine Auszeichnung von bereits zurueckliegenden Eintraegen notwendig ist. Dazu muesste ich die alten Eintraege vor dem Rausschreiben noch zwischenpuffern, so habe ich aber das awk script nicht organisiert, das kann nur bereits zurueckliegende Ereignisse beruecksichtigen. Diese Berechnung ist mit ein Grund das in Perl umzuschreiben, zumal dort auch Libraries fuer Datumsarithmetik existieren. (Wann ist "dawn" wenn "bed" am 28.2. um 23:30 eingetragen ist?)
:pappnase: Tatjana
-
Die Zeitslots nach Lehmann/Deutsch sind im Datenmodell in zwei Feldern drin: ein "Timestamp", der manuell eingetragen wird ((Aufstehen), Fruehstueck, Mittagessen, Abendessen, Einschlafen), und ein Feld fuer die 13 "Timeslots", die daraus abgeleitet werden.
Dafür wären dann Events gut, hier hätte man die vollkommene Freiheit auch um Mitternacht eine Mahlzeit als Mittagessen zu deklarieren.
Schöner ist es zwar wenn man solche Dinge nicht angeben muss, aber ich denke bei einem Spezial-Fall z.B. Nachtschicht würde es gar nicht anders gehen - oder :kratz:
Oder es bliebe nur die Möglichkeit für jeden Tag/Zeitraum die Timeslots zu definieren, das wäre vielleicht auch eine Lösung
und man bräuchte keine Events. Für die Definitionen könnte man dann eine Vorlage auswählen und diese ggf. anpassen....
Für die Leute die diese Situation nicht haben oder die Funktion nicht nutzen möchten, sollte das dann einfach per Oberfläche deaktiviert werden können.
So köönte ich mri eine Lösung des Problems vorstellen...
Lord
-
Vielen Dank für die Erläuterungen, werde das ganze mal bei meinem nächsten Quartalscheck bei
meinem Doc ansprechen.
Wunder dich aber nicht, wenn er dich deswegen schief anguckt. Das Thema 'i.v.-Korrektur' wird nämlich sehr kontrovers betrachtet.
Zunächst einmal braucht man dafür Einmalspritzen. Mit dem Pen eht es nicht, weil man damit nicht aspirieren kann (=Stempel zurückziehen um zu sehen, daß Blut in die Spritze tritt. Kommt kein Blut in die Spritze liegt die Kanüle nicht korrekt in der Vene)
Ganz unkritisch ist diese Methode nicht. Zwar kann man nicht so ohne weiteres eine Arterie anpunktieren (die liegen nämlich tiefer nterder Haut als Venen), aber du könntest nach erfolgreichem Aspirieren die Vene durchstechen. Dann spritzt du das Insulin außerhalb der Vene (paravenös). Bei Insulin passiert da nichts, weil das ja normal auch nicht venös gespritzt werden muß, aber das kann trotzdem problematisch sein.
Wenn du 1/2 Stunde später den BZ misst und es hat sich nicht viel getan kannst du nicht sicher sein, ob es jetzt an der Dosis lag oder ob nicht doch etwas para gelaufen ist.
Gehst du dann von "Dosis unzureichend" aus und spritzt etwas nach ist die Hypo vorprogrammiert. (Denn auch das paravenös gelandete Insulin wird noch seine Wirkung entfalten)
Wenn du durch eine i.v.-Korrektur zu nah am Zielpunkt landest darfst du dich auf heftige Hypo-Symptome vorbereiten. (weil die Stärke einer Hypo direkt proportional zur Sinkgeschwindigkeit des BZ ansteigt)
Weiter ist zu berücksichtigen, daß s.c.-Insulin nie zu 100% biologisch wirksam wird. (Etwas davon wird immer vorher durch Enzyme unwirksam). i.v. ist es aber zu fast 100% wirksam.
Das alles sollte man dabei berücksichtigen. Und man sollte sich die Technik von medizinischem Fachpersonal zeigen lassen, bevor man loslegt.
Nötig ist es IMHO aber definitiv nicht, wenn man mit seinen Korrekturregeln vertraut ist. Ich krieg auch einen 400er locker in meinen Zielbereich zurück. Dauert nur etwas länger (ca. 3-4 Stunden)
-
Hallo Tatjana,
Hallo Norbert,
Wenn Du noch am modelieren des Datenmodels bist biete ich an mich daran zu beteiligen. Wenn Du das willst.
Zur Not Programiere ich auch etwas in Perl. Ich bin gerade auch dabei mir Gedanken über ein Datenmodel zu machen wobei der Schwerpunkt bei Pumpentherapie liegt.
Es ist nach meinem Verständnis gar nich so einfach die Paramter aufzuschreiben die Meßwerte bzw. andere Informationen eindeutig auswertbar machen.
Gerne - lass uns das am besten in einem separaten Thread oder per Mail diskutieren. -hier nur kurz als Antwort auf die von Dir angesprochenen Punkte:
Die Einschlafzeit ist mit drin - der Blaue Balken oben ueber dem BZ-Graph beginnt zum Einschlafzeitpunkt (E) und hoert mit dem Aufstehen auf ;) Das Zeitmodell nach Lehmann/Deutsch ist nicht am Tagesablauf sondern am circadianen Rhytmus orientiert (ist das das, was Du "Biorhytmus" nennst?), damit ist es auch fuer Schichtarbeiter, Informatiker und andere Nachteulen brauchbar. "Frauenspezifisches" ist momentan noch nicht komplett ausmodelliert - bisher nur als Buchstabe ueber dem Graph, so wie die Katheter, Ampullenwechsel, etc. Da laesst sich mehr machen, zumal bedingt durch entsprechende Verhuetungstaktiken viele Frauen darueber sowieso ein Protokoll fuehren (Basaltemperatur, Eisprung, Menstruation, zyklussteuernde Medikamente (Pille)).
Blutzuckerwert: entweder in mmg/dl oder mmol, wobei beide auch gemischt benutzt werden koennen (z.b. wenn ein Ersatzgeraet oder eine Messung durch jemand anders in der jeweils anderen Einheit daherkommen). Das Geraet ist selbstverstaendlich eindeutig identifiziert - warum Du einen Hash ueber die vorhergehenden Werte vorsehen wuerdest habe ich noch nicht verstanden?
Viele Gruesse, Tatjana
warum ich einen Hash Wert bilden will ist folgender: Es macht für mich keinen Sinn den Namen des BZ Messgerätes und die Seriennummer des Gerätes mit jedem BZ Wert zu speichern, wenn man das zum Einlesen nimmt und BZ Wert, Einheit(?) relevanten Zeiten, Messgerätseriennummer, Name des Gerätes und daraus einen 128 Bit hash bildet ist der hash ein kleinerer Datensatz als etwas wie FreestyleMini1341234123412343412.
Nach dem Berechnen des Hashes werden Name des BZ Messgerätes und die Seriennummer verworfen. Und von der Kollisionswahrscheinlichkeit sollte MD5 oder SHA ausreichen. Und das findet man als fertige Funktion in jeder Programiersprache. Der Hashwert ist auch eindeutiger Identifier für den Wert wenn man das z. B. vom PDA auf den PC Synct um keine dopppelten Werte zu erzeugen.
Mein Datenmodel sollte natürlich nicht nur CSII sondern auch ICT abdecken. Den Ansppruch CT bzw. Tabletten abzudecken habe ich jedoch nicht.
Werde mir mal meine Kontaktdaten per BM schicken damit wir das außerhalb des Forums diskutieren können. Ich will ja auch keinen Ärger mit Alf haben weil wir an einem Konkurenzprodukt arbeiten könnten. Außer Alf hat daran Interesse weil er selbst in SiDiary einbauen will.
Grüßle
Norbert
-
Hi Norbert,
mach Dir mal keine Gedanken! ;)
Aber Grund dieser Wunschliste und auch der anderen Threads ist es natürlich, die Änderungen/Erweiterungen für die nächste SiDiary-Generation mit besserer Pumpi-Unterstützung zu sammeln.
Dass ich mich an den Diskussionen nicht beteilige liegt nicht daran, dass ich keinen Bock habe, das in SiDiary einzubauen, ganz im Gegenteil. Es ist nur so, dass ich als Nicht-Pumpi einfach nicht mit diskutieren kann, was Sinn macht und was nicht... :zwinker:
Ich habe auch noch Tatjanas Email mit den Verbesserungsvorschlägen sicher in meinem Eingangspostfach verwahrt. Im Moment will ich nur erst mal noch die restlichen Treiber fertig kriegen bevor ich größere Baustellen im Hauptprogramm aufreisse, deshalb tut sich bei der Erweiterung für die Pumpenfeatures _noch_ nichts...
Viele Grüße, Alf.
-
Wunder dich aber nicht, wenn er dich deswegen schief anguckt. Das Thema 'i.v.-Korrektur' wird nämlich sehr kontrovers betrachtet.
Zunächst einmal braucht man dafür Einmalspritzen. Mit dem Pen eht es nicht, weil man damit nicht aspirieren kann (=Stempel zurückziehen um zu sehen, daß Blut in die Spritze tritt. Kommt kein Blut in die Spritze liegt die Kanüle nicht korrekt in der Vene)
Ganz unkritisch ist diese Methode nicht. Zwar kann man nicht so ohne weiteres eine Arterie anpunktieren (die liegen nämlich tiefer nterder Haut als Venen), aber du könntest nach erfolgreichem Aspirieren
Hallo Jörg,
vielen Dank für die ausführliche Antwort :)
Ich glaube dann denkt der doch bald jetzt dreht der aber wirklich durch...
ist jetzt schon so das er der Meinung ist ich habe alles zu scharf eingestellt.
Ist vielleicht auch manchmal so, aber auf der anderen Seite ist es bei mir sehr empfindlich und da reichen minimale Mengen
z.B. 0,2 I.E. bei bestimmten Bedingungen um den BZ je nachdem enorm zu senken oder das der BZ mächtig in die höhe schnellt.
Aus Deiner Antwort schliesse ich das es nicht notwendig ist i.v. zu injezieren und auch die subkutane Injektion vollkommen ausreichend ist.
Werde aber aus Interesse dochmal Fragen... bin gespannt wie er reagiert :zwinker: :lachen:
Lord
-
Hallo Jörg,
Wenn du 1/2 Stunde später den BZ misst und es hat sich nicht viel getan kannst du nicht sicher sein, ob es jetzt an der Dosis lag oder ob nicht doch etwas para gelaufen ist.
Gehst du dann von "Dosis unzureichend" aus und spritzt etwas nach ist die Hypo vorprogrammiert. (Denn auch das paravenös gelandete Insulin wird noch seine Wirkung entfalten)
Wenn du durch eine i.v.-Korrektur zu nah am Zielpunkt landest darfst du dich auf heftige Hypo-Symptome vorbereiten. (weil die Stärke einer Hypo direkt proportional zur Sinkgeschwindigkeit des BZ ansteigt)
Das alles sollte man dabei berücksichtigen. Und man sollte sich die Technik von medizinischem Fachpersonal zeigen lassen, bevor man loslegt.
Man kann mit i.v. nicht nur korrigieren sondern auch feststellen ob man eine Lipolyse hat und dan auf Shema B einsteigen.
Man sollte sich das zeigen lassen und wissen was man macht.
Problematisch ist es sicher wenn man nicht in die Vene trifft sondern subcutan das insulin zuführt.
Dumm ist es wenn man mit den wenigen Einheiten i.v. bei s.c. in den Unterzucker kommen würde aufgrund der Korrekturrate und dann nicht trifft. Dann ist der Unterzucker leider vorprogrammiert.
Wegen der Doppelwirkung darf man auch nur s.c oder i.v. machen und nicht beides gleichzeitig.
Wenn man bei i. v. die richtige Dosis wählt geht das ganze Unterzuckerfrei über die Bühne, lediglich der BZ kann etwas niedrig sein.
Grüßle
Norbert
-
Ich glaube dann denkt der doch bald jetzt dreht der aber wirklich durch...
Könnte dir passieren, ja :zwinker:
...aber auf der anderen Seite ist es bei mir sehr empfindlich und da reichen minimale Mengen
z.B. 0,2 I.E. bei bestimmten Bedingungen um den BZ je nachdem enorm zu senken oder das der BZ mächtig in die höhe schnellt.
Ein Grund mehr darauf zu verzichten.
Die letzten i.v.-Regulierungen hab ich auch nicht bei mir, sondern bei meinen Pat. durchgeführt. Aber auf Intensiv lief das eh ein bißchen anders. Da haben wir Insulin grundsätzlich i.v. gegeben, weil das einfach besser steuerbar ist. Perfusor (Spritzenpumpe) mit 50 IE auf eine 50ml Spritze (dann ließ sich das sehr einfach berechnen). Aber da liefen ja auch noch jede Menge anderer Sachen i.v. und im Notfall konnte man sehr schnell Insulin stoppen und die Glucose ein bißchen schneller laufen lassen.
Jedenfalls hatte das den Vorteil, daß man anhand der Grunddosis schon abschätzen konnte, wie ein möglicher Korrekturbolus auszufallen hatte.
-
Man kann mit i.v. nicht nur korrigieren sondern auch feststellen ob man eine Lipolyse hat und dan auf Shema B einsteigen.
Kann man mit einer normalen C-Korrektur auch. Und manchmal weiß man auch einfach, daß man ein bißchen mehr braucht.
Man sollte sich das zeigen lassen und wissen was man macht.
Yep. Für jeden ist das eh nicht geeignet.
-
Man sollte sich das zeigen lassen und wissen was man macht.
Na das versteht sich von selbst, also das würde ich niemals so machen ohne das mit meinem Doc zu besprechen und
mir das auf jedenfall zeigen lassen. :ja:
Selbst mit zeigen ist bei mir da doch eine eher zurückhaltende Haltung so selber i.v. injezieren... , aber neuen Dingen bin ich
jetzt grundsätzlich aufgeschlossener.
Wann man das macht und was das bringt hat mich mal interessiert, da ich das jetzt immer öfters gelesen habe.
Lord
-
Die Graphik ist uebrigens mit meinem kleinen awk script und gnuplot erstellt. Die Summe der Basalrate unten ist geschummelt, die korrekte Summenbildung mache ich wenn ich das auf perl umgestellt habe. Die BR ist noch einmal nach oben gespiegelt, da ich die Bolusgaben, die mit der Pumpe erfolgt sind, dort flaechentreu mit hineinzeichnen moechte, auch das wird erst mit dem Perl script geschehen, ist aber ein Beiepiel dafuer was machbar ist, wenn das Datenmodell das zulaesst. Die violette Linie stellt die morgentlichen Nuechternwerte beim Aufstehen dar, zusammen mit der Summe der Gesamtinsulinmenge (IGS) als Indikator fuer den aktuellen Stand der up/down Regulation.
Hallo,
ich beschäftige mich auch mit der visualisierung der gesammelten DM Daten mittels gnuplot. So weit wie Du bin ich damit noch nicht gekommen, aber vielleicht können wir ja zu mehreren daran arbeiten.
-
Hallo Norbert,
z. B. habe ich für einen Blutzuckerwert folgende Daten im Kopf die man speichern sollte.
Bluztuckerwert, Einheit, Tageszeit, Absolute Zeit (z. B. unix Zeit Stamp), Biorythmuszeit (schließlich ist die ja wichtig), eindeutiger Identifier für den BZ Wert (z.B. md5,sha, sha-160 Wert der vorigen Werte und Messgerätyp und Messgerätseriernnummer) damit man zwischen verschiedenen Geräten bzw. Programmen problemlos sync. machen kann.
Zusätlich fällen mir als Punkte ohne Anspruch auf Vollständigkeit noch ein: Bludruckwert, Hba1c, Einschlafzeit (Biorythmus reset :-D), Frauenspezifisches, Basalrate, Faktoren inkl. Faktorenberechnung über Basalrate für die Biorthmuszeit, ......
Die meisten Daten wirst Du nicht automatisch ermitteln können, mußt sie also eintragen. Meinst Du nicht, daß Du dann ständig nur mit der Datenerfassung beschäftigt bist? Dann würde auch die Enttäuschung groß, wenn trotzdem alle anderen Daten im Normbereich liegen, es Dein BZ nicht ist.
-
Hallo Tatjana,
Wenn das geschieht laesst sich aus Sorte und Menge auch ein (modellhaftes) Wirkprofil abbilden, so dass eine kontinuierliche graphische Darstellung des (theoretisch!) gerade wirkenden Insulins moeglich wird. Die Realitaet wird davon immer abweichen, ich halte eine solche Darstellung jedoch fuer trotzdem hilfreich. Fuer den Benutzer ist der Aufwand gleich...
Damit bin ich nicht recht klargekommen. Ich habe das mehrere Jahre lang mit ZuckTage bzw. DiabetesManager (auf Psion) gehabt, einen Erkenntnisgewinn brachte es mir nicht, da es doch zu ungenau war. Ein Wirkprofil -- selbst wenn die Menge einbezogen wird -- ist halt doch sehr näherungsweise.
-
Hallo Norbert,
z. B. habe ich für einen Blutzuckerwert folgende Daten im Kopf die man speichern sollte.
Bluztuckerwert, Einheit, Tageszeit, Absolute Zeit (z. B. unix Zeit Stamp), Biorythmuszeit (schließlich ist die ja wichtig), eindeutiger Identifier für den BZ Wert (z.B. md5,sha, sha-160 Wert der vorigen Werte und Messgerätyp und Messgerätseriernnummer) damit man zwischen verschiedenen Geräten bzw. Programmen problemlos sync. machen kann.
Zusätlich fällen mir als Punkte ohne Anspruch auf Vollständigkeit noch ein: Bludruckwert, Hba1c, Einschlafzeit (Biorythmus reset :-D), Frauenspezifisches, Basalrate, Faktoren inkl. Faktorenberechnung über Basalrate für die Biorthmuszeit, ......
Die meisten Daten wirst Du nicht automatisch ermitteln können, mußt sie also eintragen. Meinst Du nicht, daß Du dann ständig nur mit der Datenerfassung beschäftigt bist? Dann würde auch die Enttäuschung groß, wenn trotzdem alle anderen Daten im Normbereich liegen, es Dein BZ nicht ist.
Den Blutdruck müsste ich eintragen da ich kein Blutdruckmessgeräte mit Datenschnistelle habe und falls ja wahrscheinlich auch nicht das Protokoll zum Auslesen.
Für das von mir verwendete BZ Meßgerät kenne ich das Protokoll.
Mit der Pumpe wird sicher schwieriger, vielleicht für mich nicht selbst lösbar.
Die Daten mit den unterschiedlichen Zeiten benötige ich um z. B. so nette Dinge wie Schichtarbeit und Zeitverschiebungen (z. B. Urlaub) abbilden zu können.
Ich kenne keine Software die das kann.
Wichtig bei der DM Therapie mit Pumpe: Pumpenzeit <> Tageszeit!
Und ich bin mir sicher das ich mit meinem Wissen und den Daten den DM sehr gut vorausberechnen kann.
Grüßle
Norbert
-
So habe die Umfrage bezüglich der Ereignisse jetzt geschlossen und möchte das Ergebnis hier mit
einfliessen lassen.
Frage : Würden Dich Benutzerdefinierte Pumpen-Ereignisse bei der Protokollierung unterstützen ?
Ergebnisse :
Brauche ich nicht 1 (20%)
Bedingt brauchbar 1 (20%)
Sehr hilfreich 3 (60%)
http://www.forum.diabetesinfo.de/forum/index.php/topic,1417.0.html