[LordBritish]

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 
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

Wieso nicht durchblicken  , ist doch ziemlich normal nur noch mit Abkürzungen um sich zu werfen... 
wenn ich da so an meine neues Aufgabengebiet denke...
alles nur diese besch... Abkürzungen   
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. 
 

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)

  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 

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
 

[Joerg Moeller]

...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

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

Sicherlich gibt´s auch noch die Bemerkungsspalte, aber ich liebe es Übersichtlich.
Ich empfinde es als wesentlich angenehmer/übersichtlicher, wenn´s im Grid steht. 

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.

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

[LordBritish]

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

Hatte ich nicht erwähnt Unterscheidung zw. rechts/links hat sich erledigt
Ich hatte nur noch versucht eine Sinnvolle Anwendung zu finden... 
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... 

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 

Hast Du kein Aussenlager, also ich hab eins 
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

[Quo]

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.

Tatjana

[Joerg Moeller]

Im Datenmodell von SiDiary sind, wenn man einmal davon absieht dass diverse Felder vom Benutzer beliebig umgenutzt werden koennen, Pumpen nicht wirklich vorgesehen,

 

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?

[LordBritish]

Im Datenmodell von SiDiary sind, wenn man einmal davon absieht dass diverse Felder vom Benutzer beliebig umgenutzt werden koennen, Pumpen nicht wirklich vorgesehen,

 

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 
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  und ich möchte auch keinem zu Nahe treten. 
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
 

[unknown]

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

[Joerg Moeller]

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  und ich möchte auch keinem zu Nahe treten. 

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.

[LordBritish]

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... 

Lord

[Joerg Moeller]

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... 

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!