[ralfulrich]

Und was machen wir nun mit den Standards Typ 1a oder 1b oder HIS oder NIHIS oder RIS usw...

[LordBritish]

Und was machen wir nun mit den Standards Typ 1a oder 1b oder HIS oder NIHIS oder RIS usw...

HIS & Co höre ich das erstemal, 1a, b usw. war mir ja so geringfügig von Teupe bekannt, aber genau wissen wie die definiert sind weiß ich ebenso wenig wie bei HIS & Co.

Vielleicht hat Jörg da mehr Durchblick

Ansonsten würde ich sagen einfach das übernehmen was in der ursprünglichen Vorlage war.
Wenn irgendwer etwas anderes wünscht, kann er es ja auch ändern oder?

Viele Grüße

Markus

[Attu]

Der Grund für die Änderung von 1a 1b usw. in HIS NiHIS usw.
war/ist, daß sich unter 1a 1b niemand was Vorstellen kann und auch keinen Bezug dazu hat.

HIS = High Insulin Sensibilisirung
Aber wie gesagt, ich Warte noch (hoffentlich nicht vergebens) auf Antwort.

Bin gerade nicht zuhause, werde später die Begriffe hier Postem.

Gruß Peter

[Joa]

Und was machen wir nun mit den Standards Typ 1a oder 1b oder HIS oder NIHIS oder RIS usw...

HIS & Co höre ich das erstemal, 1a, b usw. war mir ja so geringfügig von Teupe bekannt, aber genau wissen wie die definiert sind weiß ich ebenso wenig wie bei HIS & Co.

1a/1b/1ca/1cb.
Siehe: http://www.chrostek.de/wb/pages/startseite/diabetesdorf/curriculum/diabetes-typen.php

Ob da nun im Protokoll die Typenunterscheidung drin steht oder nicht, dürfte schnurzpiep sein. Der Anwender kennt seine Normen und braucht das nicht drüber zu schreiben.
Ist wohl eher so eine Art Schnellhinweis für den analysierenden Profi, der das Protokoll zur Supervision vorliegen hat.

Gruß
Joa

[Joerg Moeller]

Ist wohl eher so eine Art Schnellhinweis für den analysierenden Profi, der das Protokoll zur Supervision vorliegen hat.

Du meintest vermutlich "Teupe-Profi". Andere werden mit 1ca/1cb nichts anfangen können.

[Joa]

Du meintest vermutlich "Teupe-Profi". Andere werden mit 1ca/1cb nichts anfangen können.

Sagen wir mal "Mergentheimer Profi". Bezieht ja letztlich auch die Nomenklatur NIHIS HIS RIS ein.
Welche mir allerdings auch nicht so recht geläufig.

Gruß
Joa

[Joa]

Hallo Alf,

lechts, hechel, gieper ...  

... und dann wird es auch möglich sein, temporäre Basalraten "pro Tag" zu speichern. Wenn diese Basisarbeit erst mal erledigt ist, ist auch der Import der Daten weniger problematisch.

Na ja, bisher hab ich ja auf eine eingehender Nutzung der BR-Speicherei verzichtet, schon weil mir die BR-Liste in der Basis-Zeile irgendwann über den Kopf wächst.
Ich handel das in SD mit einem Basiszeileneintrag in der Form %(x)xx und wenn zu Ende halt mit %100 (ich nutzte eigentlich nur %uale Ratenänderungen), jeweils dann logischerweise im Verhältnis zur programmierten Rate des Tages.

Da stelle ich mir vor, dass SD die temporären Raten beim Import aus der Pumpe ja auch irgendwie zu einer Tagesgesamtrate fügen müsste? Und dass auch bei mehreren verschiedenen Änderungen am Tag. Und netterweise ebenfalls als Event in der Basiszeile ausweist?

Vielleicht wäre ja die Vereinbarung einer Syntax zum Eintrag dort ein erster Schritt?
Z. B. %xxx für prozentuale Rate ab Startzeit,
        Fx x.xxx für feste Rate ab Startzeit?

@ Ralfulrich: Könnte das Protokoll da das noch fehlende Speichermodell von SD nicht jetzt schon entsprechend rechnerisch in den BR-Darstellungen ersetzten?
Also einen syntaktisch vereinbarten Code in der BR-Zeile entsprechend auswerten, berechnen und im Protokoll darstellen?
Ist natürlich einiges an Aufwand drinne, denk ich mal.  
In der BR-Grafikdarstellung vielleicht sogar mit einer unterschiedlichen Farbe auswerten, als programmierte Veränderungen der basalen *g* BR?
Anja hielt das zumindest für machbar??  

Gruß
Joa

[Joa]

habe die fehlenden Datenverknüpfungen nachgetragen und die y Achsen im Bereich dynamisch eingestellt. Der Bereich passt sich automatisch an, je nachdem welche Werte kommen. Dadurch haben jetzt auch kleinere BR´s mehr Übersichtlichkeit...

Bei den BR's find ich die dynamische Anpassung schon sehr gut, weil sich das Raster anpasst und die Mengeneinschätzung von Änderungen dort auch erkenntlicher wird.

Bei der BZ-Kurve ist sie einerseits sinnig, andererseits aber auch etwas fraglich. Unterschiedliche Größenverhältnisse irritieren den Vergleich verschiedener Protokollwochen schon ein Wenig?
Bei hoffentlich recht linearen Verläufen über längere Zeit nicht so problematisch, aber wenn bei wem mal die Sachen größere Schwankungen zeigen?

Vielleicht besser ein Sheet mit Vorgabeoptionen zur Darstellung von BZ-Kurve und vielleicht auch BR-Größenapassung einbauen?

Auf der BZ-Kurve fände ich eine erkennbare Markierung der realen Meßwerte sinnig. Geht das? Entsprechende Datenpunkte hervorgehoben markieren?
Ist alles sicher irgenwie Kleinvieh, macht aber zusammen vielleicht auch Mist?

Die Eintragung der Notfallnummern unterliegt auch einem Copyright...

Ob es da Rechte gibt weiß ich nicht. Ich werde aber schon gefragt, ob meine Telefon oder Handynummer in einem Telfonbuch erscheinen soll/darf.
Na ja, nehmen wir nun an das Protokoll fände breitere Verbreitung, bei Leuten die dann nicht in Mergentheim sind/waren?

Was sagen die Bereitschaftsärzte der Klink, oder Teupe, wenn die ständig angeklingelt werden, ohne was abrechnen zu können, aber vor allem auch ohne irgendwas zu den Verhältnis des jeweiligen Patienten auf Lager zu haben? Das könnte stinkig machen und zu Reaktionen führen.
Na ja, und Michaels klare Sicht der Copyrights halte ich erstmal nicht für so ganz zwingend schlüssig.

Gruß
Joa

[Llarian]

Was sagen die Bereitschaftsärzte der Klink, oder Teupe, wenn die ständig angeklingelt werden, ohne was abrechnen zu können, aber vor allem auch ohne irgendwas zu den Verhältnis des jeweiligen Patienten auf Lager zu haben? Das könnte stinkig machen und zu Reaktionen führen.
Na ja, und Michaels klare Sicht der Copyrights halte ich erstmal nicht für so ganz zwingend schlüssig.

Zumal es hierzulande ganz klar eine straftat wäre, wenn sich ein Arzt ohne Kenntnis des Patientenn zu Ferndiagnose hinreißen läßt. Wird er also nicht tun. Wenn dann trotzdem ständig Anrufe kommen, wo die Leute vielleicht noch quengelig werden 2aber die Nummer steht doch drauf, nun helfen sie mir gefälligst", dann sehe ich da ein größeres Problempotential.
Und auch, wenn die Sache mit dem Copyright rein rechtlich geklärt sein sollte (ich weiß nciht, ob sie es ist), so rein von der Höflichkeit her, wärs schon ein netter Zug, das Projekt mal vorzustellen und nach der Meinung zu fragen...

Grüße
Anja

[Joa]

Der Import scheitert im Moment an Dreierlei wesentlichen Dingen:

Das momentane Speichersystem von SiDiary erlaubt es nicht, für einen Tag eine temporäre Basalrate abzuspeichern,

  Warum eigentlich nicht?

bislang kann lediglich ein Link auf eine Basalrate (temporär oder dauerhaft) aus der Basalratenverwaltung gespeichert werden.

Es gibt pro Tag *immer*  nur eine Basalrate, so sehr man diese auch dreht oder wendet oder auch (P)ab-legt/-stellt.

Lord hat genau das sehr penibel und mit sehr viel Aufwand durchgezogen und jetzt als Dank ich weiss nicht wieviele 100 Basalraten gespeichert...

Dabei hätte es doch auch gereicht, für jeden Tag eine davon zu speichern? *gg*
Im 2D-Modell der Daten in einer eigenen Tabelle, oder auch irgendwie in den Tagesdaten?
Auf Wunsch könnte das Gesamtkunstwerk aus BR + TBR('s) auch unter aussagefähigem Namen in der BR-Verwaltung als Template für die Basis-Zeile abgelegt werden?
Das bedingte denne aber wohl eine Berechnung der BR je Tag und bis zum Wirken eines neuen Speichersystems eine Eingabekonvention von TBR-Events für die Basiszeile (siehe auch weiter oben)? Kommt jetzt natürlich drauf an, ob SD 6 schon vor der Tür steht oder noch eher Zukunftsmusike ist.

Aber das ist nat. sub-optimal, deswegen werden wir für die neue Version (u.a.) das komplette Speichersystem für SiDiary umstellen

Lass mich raten. SD kommt in die Schule, was mit 6 ja nicht unüblich? Im Fach Rechnen steht relationale Datenmathematik auf dem Stundenplan?

und dann wird es auch möglich sein, temporäre Basalraten "pro Tag" zu speichern. Wenn diese Basisarbeit erst mal erledigt ist, ist auch der Import der Daten weniger problematisch.

Du machst mich neugierig, wie das aussehen wird.

Lord hat uns da schon mit diversen Testdaten unterstützt aber je mehr wir haben desto besser, so gesehen her damit

Wieviele Testbasalraten brauchst Du noch?  

Aber der Gedanke an die Abbildung der BR's hat mich ja auch mal wieder beim Teupe-Protokoll bewegt.
Ralf natürlich noch mehr, so dass er nun schon bei der dritten Nachkommastelle des Insulins gelandet ist.  

Nimmt man das Mergentheimer Protokoll, so beschränkt dieses sich auf 24 volle Stunden und BR-Abschnitte. Was der historischen Anbindung dort an Disetronic entspringt. Minimed hatte sich dagegen denn recht frühzeitig mit 48 möglichen Stufen zu profilieren gesucht. Die lassen sich allerdings auch in x-Zwischenstufen, eben max. 48, einstellen. Also z.B. Start1 =0:00 / Start2= 4:30 / Start3= 9:00 ...

Derzeit müssen Anwender des Protokolls ihre BR tatsächlich oder zumindest gedanklich in 24 BR-Schritte aufteilen. Aber wohl auch Mergentheim/Althausen Anwender.
Was aber wenn jemand eine 48-Raten-Pumpe auch noch voll ausreizen wollte?
Ok, wer 48 Raten ausprogrammierte, und auch noch in ständigen Wechseln, hätte sowieso ein Problem, das mit Datenerfassung alleine nicht mehr zu lösen sein dürfte.    

Gruß
Joa