Contour USB auch unter Linux / Datenexport in XML ohne Glucofacts

[Marcel Bensch]

Hallo Leute,

seit Dezember bin ich stolzer Besitzer des Contour USB von Bayer.
Wie die meisten sicherlich wissen ist die mitgelieferte Software nicht
grade der
Bringer und man hat auch keine Möglichkeit des Datenexports um die
Daten
in anderen Programmen (z.B. SiDiary) zu nutzen. Dazu kommt noch, dass
Bayer bisher nur Windows und Mac Systeme unterstützt.

Aufgrund dieser Problematik habe ich mir die Mühe gemacht und ein
Reverse Engineering
des Protokolls betrieben. Auf der Basis meiner Erkenntnisse habe ich
dann ein kleines Programm
geschrieben welches die Werte aus dem Contout USB auslesen kann.

Das Ganze ist zu 80% fertig und wurde bis jetzt unter Linux getestet.
Sobald ich den Grundkern stabil habe ( was in so ca. 3-4 Tagen der
Fall sein dürfte) werde ich noch einen Parser schreiben, der die Daten
in XML, bzw CSV exportieren kann.

Wer Interesse an näheren Informationen hat oder mich bei der
Entwicklung unterstützen möchte,
kann sich ja gerne melden (Leute mit Erfahrung in C und der libhid
Library währen ein Segen).

Wenn es News gibt, werde ich wieder hier schreiben.

Liebe Grüße,

Marcel

Melde mich wieder wenn es News gibt ;-)

So far, schöne Grüße,

Marcel

[Torsten Mueller]

Post by Marcel Bensch
Das Ganze ist zu 80% fertig und wurde bis jetzt unter Linux
getestet. Sobald ich den Grundkern stabil habe ( was in so ca. 3-4
Tagen der Fall sein dürfte) werde ich noch einen Parser schreiben,
der die Daten in XML, bzw CSV exportieren kann.

Machma einen Vorschlag für das XML-Format, was da rauskommen soll.
D.h. für ein allgemein nutzbares, lesbares Format von
BZ-Meßgerät-Daten. (Nicht, daß ich mir selber solches nicht vorstellen
könnte, aber mir geht es darum, wie andere das sehen. Ich hab auch
nicht so den Überblick, welches Gerät was kann.) Interessant wäre also
eine XSD, die nicht nur ein gerät abdeckt und über die man öffentlich
diskutieren könnte.

Vielleicht fangen wir mit CSV an. Was brauchts da?

n Zeilen mit jeweils Zeitstempel, Meßwert

T.M.

[Marcel Bensch]

Post by Marcel Bensch
Das Ganze ist zu 80% fertig und wurde bis jetzt unter Linux
getestet. Sobald ich den Grundkern stabil habe ( was in so ca. 3-4
Tagen der Fall sein d rfte) werde ich noch einen Parser schreiben,
der die Daten in XML, bzw CSV exportieren kann.

Machma einen Vorschlag f r das XML-Format, was da rauskommen soll.
D.h. f r ein allgemein nutzbares, lesbares Format von
BZ-Me ger t-Daten. (Nicht, da ich mir selber solches nicht vorstellen
k nnte, aber mir geht es darum, wie andere das sehen. Ich hab auch
nicht so den berblick, welches Ger t was kann.) Interessant w re also
eine XSD, die nicht nur ein ger t abdeckt und ber die man ffentlich
diskutieren k nnte.
Vielleicht fangen wir mit CSV an. Was brauchts da?
n Zeilen mit jeweils Zeitstempel, Me wert
T.M.

Das XML Format werde ich natürlich allgemein beschreiben und eine DTD
mitliefern.
Da ich auch vorhabe das später für andere Geräte zu Portieren könnte
ich mir folgendes vorstellen:

So ziemlich jedes Gerät dass ich kenne speichert ja mindestens den
Wert, die Einheit in der gemessen wurde und meistens noch diverse
Flags (vor dem Essen, nach dem Essen). Auch liefern alle Geräte
Informationen über sich selber (Name, Hersteller, Seriennummer,
etc.). Auf dieser Basis werde ich heute Abend mal ein Schema
erarbeiten und dann hier zur Diskussion stellen. Ich will jetzt keine
vorschnellen Sachen hier posten, da ich sehr darauf bedacht bin
Standards einzuhalten und alles möglichst portierbar zu halten.

Kurze Info speziell zum Contour USB:

Die Daten ankommen sind jeweils 64byte in hex.

Als Erstes lifert das Gerät 4 Datensätze:

1. Infos über das Gerät:
A B C <  1 H | \ ^ & | | m M 7 d u M | B a y e r 7 3 9 0 ^ 0 1 . 2 0
\ 0 1 . 0 4 \ 0 2 . 0 4 . 1 9 ^ 7 3 9 0 - 1 0 2 5 0 4 8 ^

2. Verschiede Statusflags:
A B C < 7 3 9 1 - | A = 1 ^ C = 6 3 ^ G = 1 ^ I = 0 1 0 0 ^ R = 2 ^ S
= 1 ^ U = 0 ^ V = 1 0 6 0 0 ^ X = 0 7 0 0 9 0 0 9 0 0 9 0

3. Nochmehr Statusflags (unter anderem die Anzahl der gespeicherten
Werte - hier jetzt 87)
A B C < 1 8 0 1 2 0 1 8 0 1 8 0 ^ Y = 3 6 0 1 2 6 0 9 0 0 5 0 0 9 9 0
5 0 3 0 0 0 8 9 ^ Z = 1 | 8 7 | | | | | P | 1 | 2 0 1 0 0

4. Datensatz der wahrscheinlich mitteilen soll das hier Ende ist und
eine neue Anfrage gesendet werden muss.

Auf die nächste Anfrage liefert das Gerät eine Antwort die ich bis
jetzt noch nicht interpretieren konnte, welche aber wohl zuerst
gelesen werden muss, bevor man an die eigentlichen Werte dran kommt.

Ab jetzt folgt auf jede weitere Anfrage ein Datensatz mit einem
Messwert in folgender Form:
A B C 2  3 R | 1 | ^ ^ ^ G l u c o s e | 8 8 | m g / d L ^ D | | A |
| 2 0 0 9 1 2 1 8 0 9 1 1

Die 1 ist der Index des Wertes, 88 der Wert, dann folgt die Einheit,
das A ist das Flag für nach dem Essen (after food) und B wäre hier für
vor dem Essen (before food) [nähres zu den flags kann man aus der
meterdefiniton.xml für das APOLLO entnehmen, welche man in den
Verzeichnissen von Glucofacts findet], und danach folgt das Datum und
die Uhrzeit (2009/12/18 09:11 Uhr)

Momentan muss ich noch das Intervall rausfinden in dem ich die
Kontrollanfragen sende um das Gerät bzw die Pipes nicht zu überlasten.
Sobald ich das Problem gelöst habe fang ich an den Parser zu
schreiben. Sobald alles fertig ist werde ich noch eine Library daraus
bauen mit einer API, damit man das Ganze auch in eigene Anwendungen
integrieren kann.

Soweit so gut, bis heute Abend.

Marcel

[Marcel Bensch]

Post by Marcel Bensch
Das XML Format werde ich natürlich allgemein beschreiben und eine DTD
mitliefern.

So im folgenden habe ich mal ein Schema in Form einer DTD und einer
Demo XML erarbeitet,
und durch Validome validieren lassen.

Der Link zum Validator samt den Sourcefiles:

http://tinyurl.com/ycz29hr

Habe es bewusst simpel gehalten um es möglichst weit einsetzbar zu
machen.
Das Attribut status hat eine Enumeration welche folgende Bedeutung
hat:

AF = After Food = Messung nach dem Essen
BF = Before Food = Messung vor dem Essen
CO = COntrol = Kontrollmessung bzw. Messgerätkalibration (Der Wert
sollte in dem Fall ignoriert werden)

Bitte postet mal Feedback und Anregungen.

Mfg,

Marcel

[Christoph 1]

Post by Torsten Mueller
Vielleicht fangen wir mit CSV an. Was brauchts da?
n Zeilen mit jeweils Zeitstempel, Meßwert
T.M.

Die Daten, die ich aus der MiniMed Paradigm Pumpe als CSV exportiern
kann, haben folgende Spaltenüberschriften:

Index;
Datum;
Zeit;
Zeitstempel;
Neue Gerätezeit;
BZ-Messwert (mg/dl);
ID des verb. BZ-Messgeräts;
Tempor. Basalrate (IE/h);
Art d. tempor. Basalrate;
Dauer Temp Basal (hh:mm:ss);
Bolustyp;
Gewähltes Bolusvolumen (IE);
Abgegebene Bolusmenge (IE);
Programmierte Bolusdauer (hh:mm:ss);
Füllart;
Abgegebenes Füllvolumen (IE);
Unterbrechen;
Rücklauf;
BolusExpert-Schätzung (IE);
BolusExpert: Hoher BZ-Grenzwert (mg/dl);
BolusExpert: Niedriger BZ-Grenzwert (mg/dl);
BolusExpert: KH-Faktor (Ber.einheiten);
BolusExpert: Korrekturfaktor (mg/dl);
BolusExpert: KH-Eingabe (Ber.einheiten);
BolusExpert: BZ-Eingabe (mg/dl);
BolusExpert: Geschätzte Korrektur (IE);
BolusExpert: geschätzte Nahrung (IE);
BolusExpert: Aktives Insulin (IE);
Alarm;
BZ-Wert für Sensorkalibrierung (mg/dl);
Sensorglukose (mg/dl);
ISIG-Wert;
Tages-Gesamtinsulin (IE);
Roh-Typ;
Roh-Werte;
Roh-ID;
Roh-Upload-ID;
Roh-Seq Num;
Roh-Gerätetyp

Die Werte sind für Nur-BZ-Tabellen natürlich nicht alle nötig.

Viele Grüße
Christoph

[Marcel Bensch]

Post by Marcel Bensch
Das XML Format werde ich natürlich allgemein beschreiben und eine DTD
mitliefern.

So im folgenden habe ich mal ein Schema in Form einer DTD und einer
Demo XML erarbeitet,
und durch Validome validieren lassen.

Der Link zum Validator samt den Sourcefiles:

http://tinyurl.com/yb5sprl

Habe es bewusst simpel gehalten um es möglichst weit einsetzbar zu
machen.
Das Attribut status hat eine Enumeration welche folgende Bedeutung
hat:

AF = After Food = Messung nach dem Essen
BF = Before Food = Messung vor dem Essen
CO = COntrol = Kontrollmessung bzw. Messgerätkalibration (Der Wert
sollte in dem Fall ignoriert werden)

Bitte postet mal Feedback und Anregungen.

Mfg,

Marcel

[Anja Länge]

Post by Marcel Bensch
Habe es bewusst simpel gehalten um es möglichst weit einsetzbar zu
machen.

Wie weit soll das denn gehen/erweiterbar sein? Messgeräte wie das OTUS
können deutlich mehr Daten aufnehmen und die Speicher der Pumpen liefern
ebenfalls mehr als nur Glukosewerte.
Ich würde ein weiteres Element "Typ" einfügen, um beliebige Arten von Daten
aufnehmen zu können.
_Wenn_ das Modell mehrere Datentypen aufnehmen können soll, würde die
Einheit allerdings in den Record gehören, weil es z.B. mmHg, g, IE, °C, min
auch noch geben kann.


Anja

[Marcel Bensch]

Habe es bewusst simpel gehalten um es m glichst weit einsetzbar zu
machen.

Wie weit soll das denn gehen/erweiterbar sein? Messger te wie das OTUS
k nnen deutlich mehr Daten aufnehmen und die Speicher der Pumpen liefern
ebenfalls mehr als nur Glukosewerte.
Ich w rde ein weiteres Element "Typ" einf gen, um beliebige Arten von Daten
aufnehmen zu k nnen.
_Wenn_ das Modell mehrere Datentypen aufnehmen k nnen soll, w rde die
Einheit allerdings in den Record geh ren, weil es z.B. mmHg, g, IE, C, min
auch noch geben kann.
Anja

In diesem Beispiel ging es erstmal nur speziell um Glukosewerte.
Eine allgemeinere Definition wäre natürlich möglich, hierzu kann ich
ja auch einmal ein Schema ausarbeiten,
aber das sollten wir dann gesondert behandeln denke ich. Ich werde
dieses Schema trotzdem noch einmal
überarbeiten und morgen eine aktualisierte Version zur Diskussion
stellen.

Jetzt ruft mich erstmal mein Bett.

Mfg,

Marcel

[Torsten Mueller]

Post by Anja Länge
Ich würde ein weiteres Element "Typ" einfügen, um beliebige Arten von
Daten aufnehmen zu können.

Ja. Oder halt der Name einer Meßreihe, wie immer man es nennen will.

Post by Anja Länge
_Wenn_ das Modell mehrere Datentypen aufnehmen können soll, würde die
Einheit allerdings in den Record gehören, weil es z.B. mmHg, g, IE,
°C, min auch noch geben kann.

Prinzipiell ja. Die Einheit spielt am Empfänger allerdings nur dann eine
Rolle, wenn sie entweder gänzlich unbekannt ist (das trifft nicht zu)
oder unvorhersehbar wechselt (das träfe zu, wenn man beispielsweise ein
anderes Meßgerät benutzt).

Ich würde die Einheit draußen lassen und als Regel vereinbaren, daß
diese nicht wechseln _darf_. Der Wechsel der Einheit mitten in einer
Meßreihe hätte auch ernsthafte Konsequenzen am Empfänger.

T.M.

[Marcel Bensch]

Post by Torsten Mueller

Post by Anja Länge
Ich würde ein weiteres Element "Typ" einfügen, um beliebige Arten von
Daten aufnehmen zu können.

Ja. Oder halt der Name einer Meßreihe, wie immer man es nennen will.

Post by Anja Länge
_Wenn_ das Modell mehrere Datentypen aufnehmen können soll, würde die
Einheit allerdings in den Record gehören, weil es z.B. mmHg, g, IE,
°C, min auch noch geben kann.

Prinzipiell ja. Die Einheit spielt am Empfänger allerdings nur dann eine
Rolle, wenn sie entweder gänzlich unbekannt ist (das trifft nicht zu)
oder unvorhersehbar wechselt (das träfe zu, wenn man beispielsweise ein
anderes Meßgerät benutzt).
Ich würde die Einheit draußen lassen und als Regel vereinbaren, daß
diese nicht wechseln _darf_. Der Wechsel der Einheit mitten in einer
Meßreihe hätte auch ernsthafte Konsequenzen am Empfänger.
T.M.

Die Einheit ist ja erstmal Gerät abhängig. Eine Pumpe spritzt Insulin,
also haben wir hier Insulineinheiten - Ein Messgerät misst die Glucose
also haben wir hier mg/dL oder mmol.
Und will man aus einem Gerät dass beispielsweise auch die BE speichern
kann, diese auslesen, so ist die Einheit BE. Grunsätzlich gehe ich
einfach mal davon aus,
dass man in einer Transaktion nur einen bestimmten Typ abfragen will
und deshalb sehe ich die Einheit in der Gerätedefinition schon
richtig gesetzt.
Wir sollten uns vielleicht erst einmal darüber einigen, ob wir nun
einen Transaktionsstandard für Glucosewerte aus Messgeräten wollen
oder einen allgemeinen
für alle Diabetes-bezogenen Daten, dann müsste man da natürlich ganz
anders herangehen.
Ich ging jetzt erst mal nur von der Transaktion von Glukoseweten aus.

Mfg,

Marcel

[Anja Länge]

Post by Marcel Bensch
Die Einheit ist ja erstmal Gerät abhängig.

Es gibt nicht mehr viele Geräe, die das können, aber bei einigen kann man
die Glukose-Messeinheit umstellen.

Post by Marcel Bensch
Und will man aus einem Gerät dass beispielsweise auch die BE speichern
kann, diese auslesen, so ist die Einheit BE.

Das sind bei OTUS und den Pumpen eher Gramm-Angaben. BE ist fehleranfällig,
weil es zuviele gängige Einheiten gibt.
Außerdem gibt es z.B. OTUS-Nutzer, die in SiDiary eine Einstellung
verwenden, daß eine "1" bei Kohlenhydraten als eine halbe BE interpretiert
wird.
Gramm sind dann auch universeller, wenn Fett und Eiweiß mit gespeichert
werden.

Post by Marcel Bensch
Grunsätzlich gehe ich einfach mal davon aus,
dass man in einer Transaktion nur einen bestimmten Typ abfragen will
und deshalb sehe ich die Einheit in der Gerätedefinition schon
richtig gesetzt.

Ist ja auch prinzipiell nicht verkehrt. Schränkt aber ein. Sollen mehr Leute
als der Programmierer selbst das ganze verwenden, haben die vielleicht
andere Geschmäcker oder ihre Ärzte andere Geschmäcker.
Ich für meinen Teil weiß, dß ich mit einem Gerät mit mmol/l nie klarkommen
würde, weil ich seit 31 Jahren in mg/dl rechne und denke, insofern habe ich
kein Problem damit, bei einer für mich bestimmten Lösung nur diese Variante
zu berücksichtigen und gönne mir diesen Luxus halt.

Post by Marcel Bensch
Wir sollten uns vielleicht erst einmal darüber einigen, ob wir nun
einen Transaktionsstandard für Glucosewerte aus Messgeräten wollen
oder einen allgemeinen
für alle Diabetes-bezogenen Daten, dann müsste man da natürlich ganz
anders herangehen.
Ich ging jetzt erst mal nur von der Transaktion von Glukoseweten aus.

In ein sinnvolles Protokoll sollten zumindest noch Kohlenhydrate und Insulin
einfließen. Wenn man wirklich damit arbeiten und einen Nutzen daraus ziehen
können will, dann noch deutlich mehr. Und wenn Du Dir Gedanken und Mühe
machst, so einen Standard entwickeln zu wollen, schätze ich Dich einfach mal
so ein, daß es nicht nur eine Designstudie werden soll ;-)


Anja

[Bodo Mysliwietz]

Post by Anja Länge
Ich für meinen Teil weiß, dß ich mit einem Gerät mit mmol/l nie klarkommen
würde, weil ich seit 31 Jahren in mg/dl rechne und denke,

Na, wenn man als Friesin in ein fernes Land mit völlig anderem
Kulturkeis zieht (SCNR), nach fast ebenso langer Zeit wie man mg/dl
erlebt hat auch noch den Umstieg von der D-Mark auf Euro schaffte, dann
hat man nach 10 Jahren auch die Milimol "im Blut".

;-)

[Torsten Mueller]

Post by Bodo Mysliwietz

Post by Anja Länge
Ich für meinen Teil weiß, dß ich mit einem Gerät mit mmol/l nie
klarkommen würde, weil ich seit 31 Jahren in mg/dl rechne und denke,

Na, wenn man als Friesin in ein fernes Land mit völlig anderem
Kulturkeis zieht (SCNR), nach fast ebenso langer Zeit wie man mg/dl
erlebt hat auch noch den Umstieg von der D-Mark auf Euro schaffte,

Welchen Umstieg? Ich rechne, wenn ich in D bin, immer noch in DM - und
das Lustige ist ja: es stimmt bald wieder, jedenfalls auf der
Ausgabenseite.

Post by Bodo Mysliwietz
dann hat man nach 10 Jahren auch die Milimol "im Blut".

Ich hab's von Anfang an so gelernt und finde nicht so große Zahlen
eigentlich hypscher. Der Trick ist, glaub ich, man darf nicht an den
alten Grenz- und Vergleichswerten festhalten. Man muß die konsequent mit
umstellen.

T.M.

[Marcel Bensch]

Mal ganz kurze Offtopic Frage, nutzt von euch schon einer Google
Wave ??
Das was wir hier machen wäre ja evtl. eine sinnvolle
Einsatzmöglichkeit ;-)

Mfg,

Marcel

[Anja Länge]

Post by Torsten Mueller

Post by Bodo Mysliwietz
Na, wenn man als Friesin in ein fernes Land mit völlig anderem
Kulturkeis zieht (SCNR), nach fast ebenso langer Zeit wie man mg/dl
erlebt hat auch noch den Umstieg von der D-Mark auf Euro schaffte,

Welchen Umstieg? Ich rechne, wenn ich in D bin, immer noch in DM

*knuddel*

Du auch?


;-)
Anja

[Marcel Bensch]

Post by Anja Länge

Post by Marcel Bensch
Die Einheit ist ja erstmal Gerät abhängig.

Es gibt nicht mehr viele Geräe, die das können, aber bei einigen kann man
die Glukose-Messeinheit umstellen.

Ist ja auch kein Problem, der Wert in unit ist ja frei definierbar und
wird aus dem Gerät selbst ausgelesen.
Das heißt wenn ich das gerät abfrage nach werten muss es mir mitteilen
in welcher einheit diese werte geliefert werden.
Dies fließt dann eben in das feld unit ein ob da nun mg/dl , mmol, be,
kh oder was weiß ich drin steht, wichtig ist doch für die spätere
Verarbeitung nur:

1. Um was für ein Gerät handelt es sich (Pumpe / BZ-Messgerät etc.)
2. Hersteller und Name des Geräts rein wegen der Vollständigkeit
2. Welche Seriennummer hat das Gerät (Gerät-Patient Zuordnung)
3. In welcher Einheit sind die Werte, die mir das Gerät liefert.

Post by Anja Länge

Post by Marcel Bensch
Und will man aus einem Gerät dass beispielsweise auch die BE speichern
kann, diese auslesen, so ist die Einheit BE.

Das sind bei OTUS und den Pumpen eher Gramm-Angaben. BE ist fehleranfällig,
weil es zuviele gängige Einheiten gibt.
Außerdem gibt es z.B. OTUS-Nutzer, die in SiDiary eine Einstellung
verwenden, daß eine "1" bei Kohlenhydraten als eine halbe BE interpretiert
wird.
Gramm sind dann auch universeller, wenn Fett und Eiweiß mit gespeichert
werden.

Post by Marcel Bensch
Grunsätzlich gehe ich einfach mal davon aus,
dass man in einer Transaktion nur einen bestimmten Typ abfragen will
und deshalb sehe  ich die Einheit in der Gerätedefinition schon
richtig gesetzt.

Ist ja auch prinzipiell nicht verkehrt. Schränkt aber ein. Sollen mehr Leute
als der Programmierer selbst das ganze verwenden, haben die vielleicht
andere Geschmäcker oder ihre Ärzte andere Geschmäcker.
Ich für meinen Teil weiß, dß ich mit einem Gerät mit mmol/l nie klarkommen
würde, weil ich seit 31 Jahren in mg/dl rechne und denke, insofern habe ich
kein Problem damit, bei einer für mich bestimmten Lösung nur diese Variante
zu berücksichtigen und gönne mir diesen Luxus halt.

Wie ich bereits gesagt habe sollte man das wirklich trotzdem in
Transaktionen aufteilen.
Ich frage ein Gerät nach einem bestimmten Wertetyp an, dies liefert
mir über die API
die entsprechenden Datensätze zurück welche dann auf die XML gemappt
werden.
In einer zweiten Transaktion frage ich die anderen Datensätze ab. Das
ist auch leichter
zu implementieren da die XML die ich bekomme viel homogener ist. Die
Deviceinfo
sagt mir welches Gerät mir die Daten liefert, welche Daten geliefert
werden und in welcher einheit
und das Recordset brauch ich dann nur entsprechen durchlaufen und kann
das schön
verarbeiten.

Post by Anja Länge

Post by Marcel Bensch
Wir sollten uns vielleicht erst einmal darüber einigen, ob wir nun
einen Transaktionsstandard für Glucosewerte aus Messgeräten wollen
oder einen allgemeinen
für alle Diabetes-bezogenen Daten, dann müsste man da natürlich ganz
anders herangehen.
Ich ging jetzt erst mal nur von der Transaktion von Glukoseweten aus.

In ein sinnvolles Protokoll sollten zumindest noch Kohlenhydrate und Insulin
einfließen. Wenn man wirklich damit arbeiten und einen Nutzen daraus ziehen
können will, dann noch deutlich mehr. Und wenn Du Dir Gedanken und Mühe
machst, so einen Standard entwickeln zu wollen, schätze ich Dich einfach mal
so ein, daß es nicht nur eine Designstudie werden soll ;-)

So wie sich das gerade alles Entwickelt finde ich das schon klasse und
ich bin auch
gerne bereit da mehr Zeit zu opfern. ursprünglich ging es ja nur darum
das Contour USB
auch ohne Glucofacts einsetzen zu können. Mittlerweile entwickelt sich
das ganze in ein
größeres Projekt, was ich klasse finde :-) Denn es macht mir Spaß, ich
lern was dabei
und habe eventuell über die Tour Stoff für meine Bachelorarbeit.
Letztendlich ist das
was hier ja gemacht werden soll eine standartisierte Definition für
den Austausch von Diabetes bezogenen
Daten. Ich habe aber auch schon wieder neue Ideen und mein
ursprüngliches Konzept überarbeitet.
Werde denke ich ma morgen oder so mal ein neues Proposal zur
Diskussion stellen. Bin nur gerade zeitlich
etwas eingebunden, da ich gestern erst aus dem Kranknehaus raus bin,
heute an mein Studienort zurück muss
und morgen dann noch etliches für die UNI tun sollte und nebenbei ja
auch noch die Contour USB API und mein
Webbasiertes Diabetesmanagement Tool fertigstellen möchte.

Gott sei dank hat man mich mit Multitasking und Hyper-Threading
ausgestattet :-)

Liebe Grüße,

Marcel

[Torsten Mueller]

Also, ich mach mal eine XSD für ein offenes Format zum Datenaustausch.
(DTD ist old style, oder?)

Wesentlich ist der Gedanke, Datenwerte in typenreinen Meßreihen
anzuordnen. Ich nenne die "collections". Der Datenbestand kann aus
unbegenzt vielen collections bestehen. Jede collection speichert Paare
von Wert und Zeitstempel, wobei der Zeitstempel innerhalb der collection
jeweils eindeutig ist:

<?xml version="1.0" encoding="iso-8859-1" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" >

<xsd:element name="data">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="collection" type="collection" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:complexType name="collection">
<xsd:sequence>
<xsd:element name="value" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="datetime" type="xsd:string" />
<xsd:attribute name="value" type="xsd:string" />
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" />
<xsd:attribute name="type" type="xsd:string" />
</xsd:complexType>

</xsd:schema>

Mit dieser XSD lassen sich XML-Dateien anlegen, die beispielsweise
folgendes Aussehen haben:

<?xml version="1.0" encoding="ISO-8859-1"?>
<data>
...
<collection name="Kommentare" type="text">
...
<value date="2009-01-09 18:27:11" value="ein paar g zu viel KH in der Nachmittagsmahlzeit"/>
<value date="2009-01-10 07:52:01" value="heute 1h Sport gemacht"/>
<value date="2009-01-13 10:33:17" value="ein mittlerer Apfel um 9:30"/>
...
</collection>
<collection name="Blutzucker" type="numeric">
...
<value date="2009-01-12 12:35:00" value="5.8"/>
<value date="2009-01-12 13:57:01" value="9.3"/>
<value date="2009-01-12 14:46:45" value="5.6"/>
...
</collection>
<collection name="Basisinsulin" type="numeric">
...
<value date="2009-01-05 21:50:49" value="7"/>
<value date="2009-01-06 21:48:46" value="8"/>
<value date="2009-01-07 21:51:28" value="8"/>
...
</collection>
<collection name="Bolusinsulin" type="numeric">
...
<value date="2009-01-10 07:52:01" value="5"/>
<value date="2009-01-10 12:22:47" value="6"/>
<value date="2009-01-10 20:20:46" value="10"/>
...
</collection>
...
</data>

So ein Datenbestand läßt sich leicht und sehr schnell parsen (die Daten
einer Person und eines Jahres in einer Größenordnung von 1s). Solche
collections können anschließend leicht anhand des Zeitstempels gejoint
oder mit Aggregatfunktionen belegt werden.

Daten wie Art und Seriennummer des Meßgeräts, Maßeinheit, vor dem Essen,
nach dem Essen u.ä. wären darin leicht unterzubringen. Ich würde
allerdings das meiste davon optional machen.

Für Blutdruck übrigens wäre ein weiterer Datentyp erforderlich, der zwei
Zahlen speichern kann. Das würde allerdings hier gar kein Problem sein.
So ein value könnte leicht "80/125" lauten.

Wichtig wäre eine verbindliche Notation für Zeitstempel. Vorschlag:
YYYY-MM-DD hh:mm[:ss]

T.M.

[Marcel Bensch]

Post by Torsten Mueller
Also, ich mach mal eine XSD für ein offenes Format zum Datenaustausch.
(DTD ist old style, oder?)
Wesentlich ist der Gedanke, Datenwerte in typenreinen Meßreihen
anzuordnen. Ich nenne die "collections". Der Datenbestand kann aus
unbegenzt vielen collections bestehen. Jede collection speichert Paare
von Wert und Zeitstempel, wobei der Zeitstempel innerhalb der collection
<?xml version="1.0" encoding="iso-8859-1" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" >
  <xsd:element name="data">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="collection" type="collection" minOccurs="0" maxOccurs="unbounded" />
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:complexType name="collection">
    <xsd:sequence>
      <xsd:element name="value" minOccurs="0" maxOccurs="unbounded">
        <xsd:complexType>
           <xsd:attribute name="datetime" type="xsd:string" />
           <xsd:attribute name="value" type="xsd:string" />
        </xsd:complexType>
      </xsd:element>
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" />
    <xsd:attribute name="type" type="xsd:string" />
  </xsd:complexType>
</xsd:schema>
Mit dieser XSD lassen sich XML-Dateien anlegen, die beispielsweise
<?xml version="1.0" encoding="ISO-8859-1"?>
<data>
        ...
        <collection name="Kommentare" type="text">
                ...
                <value date="2009-01-09 18:27:11" value="ein paar g zu viel KH in der Nachmittagsmahlzeit"/>
                <value date="2009-01-10 07:52:01" value="heute 1h Sport gemacht"/>
                <value date="2009-01-13 10:33:17" value="ein mittlerer Apfel um 9:30"/>
                ...
        </collection>
        <collection name="Blutzucker" type="numeric">
                ...
                <value date="2009-01-12 12:35:00" value="5.8"/>
                <value date="2009-01-12 13:57:01" value="9.3"/>
                <value date="2009-01-12 14:46:45" value="5.6"/>
                ...
        </collection>
        <collection name="Basisinsulin" type="numeric">
                ...
                <value date="2009-01-05 21:50:49" value="7"/>
                <value date="2009-01-06 21:48:46" value="8"/>
                <value date="2009-01-07 21:51:28" value="8"/>
                ...
        </collection>
        <collection name="Bolusinsulin" type="numeric">
                ...
                <value date="2009-01-10 07:52:01" value="5"/>
                <value date="2009-01-10 12:22:47" value="6"/>
                <value date="2009-01-10 20:20:46" value="10"/>
                ...
        </collection>
        ...
</data>
So ein Datenbestand läßt sich leicht und sehr schnell parsen (die Daten
einer Person und eines Jahres in einer Größenordnung von 1s). Solche
collections können anschließend leicht anhand des Zeitstempels gejoint
oder mit Aggregatfunktionen belegt werden.
Daten wie Art und Seriennummer des Meßgeräts, Maßeinheit, vor dem Essen,
nach dem Essen u.ä. wären darin leicht unterzubringen. Ich würde
allerdings das meiste davon optional machen.
Für Blutdruck übrigens wäre ein weiterer Datentyp erforderlich, der zwei
Zahlen speichern kann. Das würde allerdings hier gar kein Problem sein.
So ein value könnte leicht "80/125" lauten.
YYYY-MM-DD hh:mm[:ss]
T.M.

Mein nächster Anlauf wäre dann auch eine XSD gewesen ;-)

Zu deinem Vorschlag:

Grundsätzlich finde ich dein Ansatz klasse, aber eine kleine
Anmerkungen hätte ich da doch:
Die Subnode einer Collection sollte Item heißen, da diese ja schon ein
Attribut value besitzt und auch in anderen Implementationen einer
Collection von Items gesprochen wird.

Zu dem Thema Datumsformat:

Ich würde hier ein UNIX Timestamp verwenden, da sämtliche mir
bekannten Programmiersprachen in der Lage sind, diese zu verarbeiten
und es so auch möglich ist mehrdeutige Daten zu speichern (z.B.
Basalrate 0-1 Uhr) oder halt Zeitabschnitte (3 Stunden).
Diese werden dann eben repräsentiert als Offset 1.Januar 1970 00:00:00
GMT/UTC: 3 Stunden = 0+3*60*60 = 10800.

Ein anderer Ansatz wäre es wie oben zu verwenden allerdings ohne den
Whitespace und Character, also:
YYMMDDhhmmss

Mfg,

Marcel

[Torsten Mueller]

Post by Marcel Bensch
Grundsätzlich finde ich dein Ansatz klasse, aber eine kleine
Anmerkungen hätte ich da doch: Die Subnode einer Collection sollte
Item heißen, da diese ja schon ein Attribut value besitzt und auch
in anderen Implementationen einer Collection von Items gesprochen
wird.

Ja, das leuchtet ein.

Post by Marcel Bensch
Ich würde hier ein UNIX Timestamp verwenden, da sämtliche mir
bekannten Programmiersprachen in der Lage sind, diese zu verarbeiten
und es so auch möglich ist mehrdeutige Daten zu speichern (z.B.
Basalrate 0-1 Uhr) oder halt Zeitabschnitte (3 Stunden). Diese
werden dann eben repräsentiert als Offset 1.Januar 1970 00:00:00
GMT/UTC: 3 Stunden = 0+3*60*60 = 10800.

Das würde ich nicht. Dieses Format (also ein long mit Sekunden seit
1970) ist zwar einfach, aber in vielen Sprachen eben nicht einfach so
unterstützt. Selbst die neuen C++-Klassen in der boost (ptime, date,
time_duration) erfordern eine umständliche Konvertierung solcher Werte
von Hand, bevor man sie zuweisen kann. Dieses Format wird neuerdings
übrigens auch durch einen 64bit-int aufgeweicht, der eine höhere
Genauigkeit (100ns) zuläßt. Zudem sind solche Werte auch im XML nicht
gut zu lesen. Ich plädiere ausdrücklich für ein lesbares Datumsformat.
Mit Zeitzone, meinetwegen.

Post by Marcel Bensch
Ein anderer Ansatz wäre es wie oben zu verwenden allerdings ohne den
YYMMDDhhmmss

boost-Klassen arbeiten mit "YYYY-MM-DD hh:mm:ss.nnn" (.nnn sind
Millisekunden) sowie mit "YYYYMMDDThhmmss" (das T ist das Zeichen 'T',
eine Konstante). Letztere Notation wird "non delimited iso string"
genannt. Für Datumswerte benutzen sie "YYYYMMDD" (iso).

T.M.

[Michael Sand]

Post by Torsten Mueller
Für Blutdruck übrigens wäre ein weiterer Datentyp erforderlich, der zwei
Zahlen speichern kann. Das würde allerdings hier gar kein Problem sein.
So ein value könnte leicht "80/125" lauten.

Wie wär's mit systolisch / diastolisch als einzelne Items. Wenn's
schnell gehen soll, wird ja gelegentlich auch nur der systolische Wert
dokumentiert:

| <Events>
| <Glucose>
| ...
| </Glucose>
| <Bloodpressure>
| <Sample>
| <Timestamp>2008-06-27 15:13:00.000 +0200</Timestamp>
| <LevelSystolic>125</LevelSystolic>
| <LevelDiastolic>80</LevelDiastolic>
| <Unit>mmHg</Unit>
| </Sample>
| <Sample>
| ...
| </Sample>
| </Bloodpressure>
| </Events>

Wie Du siehst, führen wir im übrigen die Masseinheit bei jedem Sample
explizit mit, was ein Joinen sicherer macht. Genaugenommen darfst Du
beispielsweise beim Glukosewert neben der Einheit (mmol/l resp. mg/dl)
auch die Kalibrierung (WholeBlood vs. Plasma) nicht vergessen.

Post by Torsten Mueller
YYYY-MM-DD hh:mm[:ss]

In unserem Java-Projekt speichern wir auch die Timezone mit ab. Damit
erreichen wir einen linearen Zeitverlauf unabhängig von
Sommer-/Winter-Zeitumstellungen und Reisen über Zeitzonengrenzen
hinaus, was für exakte Zeitreihenanalysen zwingend erforderlich ist.

Grüsse

Michael

[Marcel Bensch]

Post by Michael Sand

Post by Torsten Mueller
Für Blutdruck übrigens wäre ein weiterer Datentyp erforderlich, der zwei
Zahlen speichern kann. Das würde allerdings hier gar kein Problem sein.
So ein value könnte leicht "80/125" lauten.

Wie wär's mit systolisch / diastolisch als einzelne Items. Wenn's
schnell gehen soll, wird ja gelegentlich auch nur der systolische Wert
| <Events>
|   <Glucose>
|     ...
|   </Glucose>
|   <Bloodpressure>
|     <Sample>
|       <Timestamp>2008-06-27 15:13:00.000 +0200</Timestamp>
|       <LevelSystolic>125</LevelSystolic>
|       <LevelDiastolic>80</LevelDiastolic>
|       <Unit>mmHg</Unit>
|     </Sample>
|     <Sample>
|       ...
|     </Sample>
|   </Bloodpressure>
| </Events>
Wie Du siehst, führen wir im übrigen die Masseinheit bei jedem Sample
explizit mit, was ein Joinen sicherer macht. Genaugenommen darfst Du
beispielsweise beim Glukosewert neben der Einheit (mmol/l resp. mg/dl)
auch die Kalibrierung (WholeBlood vs. Plasma) nicht vergessen.

Post by Torsten Mueller
YYYY-MM-DD hh:mm[:ss]

In unserem Java-Projekt speichern wir auch die Timezone mit ab. Damit
erreichen wir einen linearen Zeitverlauf unabhängig von
Sommer-/Winter-Zeitumstellungen und Reisen über Zeitzonengrenzen
hinaus, was für exakte Zeitreihenanalysen zwingend erforderlich ist.
Grüsse
Michael

So gefällts mir auch gleich noch besser, weniger Attribute mehr
Elemente :-) ... morgen werde ich mal meine neue XSD online stellen.
Musste heute den ganzen Tag was für die Uni machen (ich hasse Java
-.-).

Bis dann.

Marcel

[Torsten Mueller]

Post by Michael Sand
Wie wär's mit systolisch / diastolisch als einzelne Items.

Ja, das würde aber eine eigene XML-Datenstruktur erfordern, die zu den
anderen nicht mehr kompatibel ist. Kein Problem, collections sind ja
typenrein, es ist einfach ein bißchen mehr Aufwand.

Post by Michael Sand
Wie Du siehst, führen wir im übrigen die Masseinheit bei jedem
Sample explizit mit, was ein Joinen sicherer macht.

Ja. Alles richtig. Die Frage ist immer, welchen Anspruch man hat, d.h.
ob es wirklich für alles taugen, ob man wirklich alles unterstützen
muß. Zugegeben, es wird vielleicht ein paar Leute geben, die in den
nächsten Jahren von mg/dl auf mmol/L umstellen, oder die vielleicht
auch zwei Meßgeräte haben.

Man könnte ja die Einheit übrigens auch optional machen.
Beispielsweise könnte eine collection eine default-Einheit haben.
Speichert man Werte in einer anderen Einheit, so müssen diese ihre
jeweilige Einheit dann selbst tragen, andernfalls nicht. Wäre aber
vielleicht auch schwierig auszuwerten ...

Post by Michael Sand
Genaugenommen darfst Du beispielsweise beim Glukosewert neben der
Einheit (mmol/l resp. mg/dl) auch die Kalibrierung (WholeBlood vs.
Plasma) nicht vergessen.

Wie gesagt, eine Frage des Anspruchs. Ich wäre hier zu Kompromissen
bereit, d.h. zur Annahme von Konstanten. (Ich betrachte bislang auch
die Einheit als Konstante und würde, wenn ich das Meßgerät wechsle und
in einer neuen Einheit messe, auch eine neue Meßreihe beginnen.) Ich
denke an ein alltagstaugliches Programm, nicht an Laboruntersuchungen.

T.M.

[Marcel Bensch]

Post by Torsten Mueller

Post by Michael Sand
Wie wär's mit systolisch / diastolisch als einzelne Items.

Ja, das würde aber eine eigene XML-Datenstruktur erfordern, die zu den
anderen nicht mehr kompatibel ist. Kein Problem, collections sind ja
typenrein, es ist einfach ein bißchen mehr Aufwand.

Post by Michael Sand
Wie Du siehst, führen wir im übrigen die Masseinheit bei jedem
Sample explizit mit, was ein Joinen sicherer macht.

Ja. Alles richtig. Die Frage ist immer, welchen Anspruch man hat, d.h.
ob es wirklich für alles taugen, ob man wirklich alles unterstützen
muß. Zugegeben, es wird vielleicht ein paar Leute geben, die in den
nächsten Jahren von mg/dl auf mmol/L umstellen, oder die vielleicht
auch zwei Meßgeräte haben.
Man könnte ja die Einheit übrigens auch optional machen.
Beispielsweise könnte eine collection eine default-Einheit haben.
Speichert man Werte in einer anderen Einheit, so müssen diese ihre
jeweilige Einheit dann selbst tragen, andernfalls nicht. Wäre aber
vielleicht auch schwierig auszuwerten ...

Post by Michael Sand
Genaugenommen darfst Du beispielsweise beim Glukosewert neben der
Einheit (mmol/l resp. mg/dl) auch die Kalibrierung (WholeBlood vs.
Plasma) nicht vergessen.

Wie gesagt, eine Frage des Anspruchs. Ich wäre hier zu Kompromissen
bereit, d.h. zur Annahme von Konstanten. (Ich betrachte bislang auch
die Einheit als Konstante und würde, wenn ich das Meßgerät wechsle und
in einer neuen Einheit messe, auch eine neue Meßreihe beginnen.) Ich
denke an ein alltagstaugliches Programm, nicht an Laboruntersuchungen.
T.M.

So hier nun mein versprochener neuer Vorschag:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="data">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="devices" type="t_devices"
minOccurs="0" maxOccurs="1" />
<xsd:element name="collections" type="t_collections"
minOccurs="1" maxOccurs="1" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:complexType name="t_devices">
<xsd:sequence>
<xsd:element name="device" type="t_device" minOccurs="1"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="t_device">
<xsd:sequence>
<xsd:element name="class" type="xsd:string" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="name" type="xsd:string" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="vendor" type="xsd:string" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="serial" type="xsd:string" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="unit" type="xsd:string" minOccurs="1"
maxOccurs="1" />
<xsd:element name="collection_id" type="xsd:integer"
minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="device_id" type="xsd:integer"
use="required"/>
</xsd:complexType>

<xsd:complexType name="t_collections">
<xsd:sequence>
<xsd:element name="collection" type="t_collection"
minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="t_collection">
<xsd:sequence>
<xsd:element name="item" type="t_item" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:integer" use="required" />
<xsd:attribute name="type" type="xsd:string" use="required" /
</xsd:complexType>

<xsd:complexType name="t_item">
<xsd:sequence>
<xsd:element name="datetime" type="xsd:dateTime"
minOccurs="1" maxOccurs="1"/>
<xsd:element name="value" type="xsd:string" minOccurs="1"
maxOccurs="1" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:integer" use="required"/>
</xsd:complexType>
</xsd:schema>

Demo XML:

<?xml version="1.0" encoding="UTF-8"?>
<data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://sugarbrain.de/dde.xsd">
<devices>
<device device_id="0">
<class>Glucosemeter</class>
<name>Contour USB</name>
<vendor>Bayer Healthcare LCC</vendor>
<serial>1025048</serial>
<unit>mg/dL</unit>
<collection_id>0</collection_id>
</device>
</devices>
<collections>
<collection id="0" type="numeric">
<item id="0">
<datetime>2010-01-18T12:17:00</datetime>
<value>113</value>
</item>
</collection>
</collections>
</data>


Im Folgenden dazu Erläuterungen:

- Zwischen jedem Device und einer Collection besteht in diesem Fall
eine 1:1 Beziehung, das könnte man natürlich noch in 1:n umbauen,
falls das sinnvoller ist (hier könnte Unit dann auch an die
entsprechende liste gekoppelt werden)
- Das Datumsformat wird über die XSD fest vorgegeben auf: YYYY-MM-
DDThh:mm:ss - T leitet die Zeitsektion ein (Optional kann auch noch
Zeitzone als Sting z.B. UTC oder als Offset (+|-)hh:mm angegeben
werden)
- Bei allen Elementen die mehrfach vorkommen können (Device,
Collection, Item) wird immer eine ID als Attribut mitgeführt, quasi
als Primärschlüssel die ID's dürfen für das jeweilige Set nicht
doppelt vergeben werden (kann man das noch über das XSD validieren ?)

Ansonsten sollte alles selbsterklärend sein.

Mfg,

Marcel

[Marcel Bensch]

Post by Marcel Bensch

Post by Torsten Mueller

Post by Michael Sand
Wie wär's mit systolisch / diastolisch als einzelne Items.

Ja, das würde aber eine eigene XML-Datenstruktur erfordern, die zu den
anderen nicht mehr kompatibel ist. Kein Problem, collections sind ja
typenrein, es ist einfach ein bißchen mehr Aufwand.

Post by Michael Sand
Wie Du siehst, führen wir im übrigen die Masseinheit bei jedem
Sample explizit mit, was ein Joinen sicherer macht.

Ja. Alles richtig. Die Frage ist immer, welchen Anspruch man hat, d.h.
ob es wirklich für alles taugen, ob man wirklich alles unterstützen
muß. Zugegeben, es wird vielleicht ein paar Leute geben, die in den
nächsten Jahren von mg/dl auf mmol/L umstellen, oder die vielleicht
auch zwei Meßgeräte haben.
Man könnte ja die Einheit übrigens auch optional machen.
Beispielsweise könnte eine collection eine default-Einheit haben.
Speichert man Werte in einer anderen Einheit, so müssen diese ihre
jeweilige Einheit dann selbst tragen, andernfalls nicht. Wäre aber
vielleicht auch schwierig auszuwerten ...

Post by Michael Sand
Genaugenommen darfst Du beispielsweise beim Glukosewert neben der
Einheit (mmol/l resp. mg/dl) auch die Kalibrierung (WholeBlood vs.
Plasma) nicht vergessen.

Wie gesagt, eine Frage des Anspruchs. Ich wäre hier zu Kompromissen
bereit, d.h. zur Annahme von Konstanten. (Ich betrachte bislang auch
die Einheit als Konstante und würde, wenn ich das Meßgerät wechsle und
in einer neuen Einheit messe, auch eine neue Meßreihe beginnen.) Ich
denke an ein alltagstaugliches Programm, nicht an Laboruntersuchungen.
T.M.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <xsd:element name="data">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element name="devices" type="t_devices"
minOccurs="0" maxOccurs="1" />
                <xsd:element name="collections" type="t_collections"
minOccurs="1" maxOccurs="1" />
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>
    <xsd:complexType name="t_devices">
        <xsd:sequence>
            <xsd:element name="device" type="t_device" minOccurs="1"
maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="t_device">
        <xsd:sequence>
            <xsd:element name="class" type="xsd:string" minOccurs="1"
maxOccurs="1"/>
            <xsd:element name="name" type="xsd:string" minOccurs="1"
maxOccurs="1"/>
            <xsd:element name="vendor" type="xsd:string" minOccurs="0"
maxOccurs="1"/>
            <xsd:element name="serial" type="xsd:string" minOccurs="0"
maxOccurs="1"/>
            <xsd:element name="unit" type="xsd:string" minOccurs="1"
maxOccurs="1" />
            <xsd:element name="collection_id" type="xsd:integer"
minOccurs="1" maxOccurs="1"/>
        </xsd:sequence>
        <xsd:attribute name="device_id" type="xsd:integer"
use="required"/>
    </xsd:complexType>
    <xsd:complexType name="t_collections">
        <xsd:sequence>
            <xsd:element name="collection" type="t_collection"
minOccurs="1" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="t_collection">
        <xsd:sequence>
            <xsd:element name="item" type="t_item" minOccurs="0"
maxOccurs="unbounded"/>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:integer" use="required" />
        <xsd:attribute name="type" type="xsd:string" use="required" /
    </xsd:complexType>
    <xsd:complexType name="t_item">
        <xsd:sequence>
            <xsd:element name="datetime" type="xsd:dateTime"
minOccurs="1" maxOccurs="1"/>
            <xsd:element name="value" type="xsd:string" minOccurs="1"
maxOccurs="1" />
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:integer" use="required"/>
    </xsd:complexType>
</xsd:schema>
<?xml version="1.0" encoding="UTF-8"?>
<data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://sugarbrain.de/dde.xsd">
    <devices>
        <device device_id="0">
            <class>Glucosemeter</class>
            <name>Contour USB</name>
            <vendor>Bayer Healthcare LCC</vendor>
            <serial>1025048</serial>
            <unit>mg/dL</unit>
            <collection_id>0</collection_id>
        </device>
    </devices>
    <collections>
        <collection id="0" type="numeric">
            <item id="0">
                <datetime>2010-01-18T12:17:00</datetime>
                <value>113</value>
            </item>
        </collection>
    </collections>
</data>
- Zwischen jedem Device und einer Collection besteht in diesem Fall
eine 1:1 Beziehung, das könnte man natürlich noch in 1:n umbauen,
falls das sinnvoller ist (hier könnte Unit dann auch an die
entsprechende liste gekoppelt werden)
- Das Datumsformat wird über die XSD fest vorgegeben auf: YYYY-MM-
DDThh:mm:ss - T leitet die Zeitsektion ein (Optional kann auch noch
Zeitzone als Sting z.B. UTC oder als Offset (+|-)hh:mm angegeben
werden)
- Bei allen Elementen die mehrfach vorkommen können (Device,
Collection, Item) wird immer eine ID als Attribut mitgeführt, quasi
als Primärschlüssel die ID's dürfen für das jeweilige Set nicht
doppelt vergeben werden (kann man das noch über das XSD validieren ?)
Ansonsten sollte alles selbsterklärend sein.
Mfg,
Marcel

Wegen besserer Übersicht hier nochmal im Validator:

http://bit.ly/7J8UYG

[Torsten Mueller]

Post by Marcel Bensch
<?xml version="1.0" encoding="UTF-8"?>
<data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://sugarbrain.de/dde.xsd">
<devices>
<device device_id="0">
<class>Glucosemeter</class>
<name>Contour USB</name>
<vendor>Bayer Healthcare LCC</vendor>
<serial>1025048</serial>
<unit>mg/dL</unit>
<collection_id>0</collection_id>
</device>
</devices>
<collections>
<collection id="0" type="numeric">
<item id="0">
<datetime>2010-01-18T12:17:00</datetime>
<value>113</value>
</item>
</collection>
</collections>
</data>

Sieht prinzipiell nicht schlecht aus.

Post by Marcel Bensch
- Zwischen jedem Device und einer Collection besteht in diesem Fall
eine 1:1 Beziehung, das könnte man natürlich noch in 1:n umbauen,
falls das sinnvoller ist (hier könnte Unit dann auch an die
entsprechende liste gekoppelt werden)

Es muß sicher mehrere collections von einem device geben können, also
1:n, nämlich für verschiedene Zwecke. Ich unterscheide bei mir
beispielsweise reguläre Messungen (früh, mittags, abends und spät) und
Experimentalmessungen (z.B. beim Sport oder mal nach dem Essen oder
nachts), die aber alle von ein und demselben Gerät kommen.

Post by Marcel Bensch
- Bei allen Elementen die mehrfach vorkommen können (Device,
Collection, Item) wird immer eine ID als Attribut mitgeführt, quasi
als Primärschlüssel die ID's dürfen für das jeweilige Set nicht
doppelt vergeben werden

Den items in einer collection würde ich keine id geben. Sie ist
schlicht nicht notwendig und wird sehr wahrscheinlich auch nirgends
weiter verwendet, insbesondere nicht in einer Datenbank, denn das
würde erzwingen, daß diese ids über alle XML-Dateien hinweg eindeutig
sind. Der Primärschlüssel ist der Zeitstempel. Alte Datenbankweisheit:
schaffe keine künstlichen Schlüssel, wo natürliche ausreichend sind.

Die collection id würde ich als string auslegen, "Blutzucker" oder
"Blutdruck" oder "0". Oder die collection müßte ein name-Attribut
bekommen. Irgendetwas lesbares jedenfalls. Das ist insbesondere
wichtig, wenn man mehrere collections von einem device hat und wissen
will, worin die sich nun unterscheiden.

Wenn auch der Wert (value) in einem item "binär" gespeichert wird, ich
meine nicht als string, dann wird allerdings für jeden Datentyp [1]
ein eigenes item erforderlich, z.B. ein numeric_item, wahrscheinlich
dann auch eine numeric_collection. Das hätte bessere
Validierungsmöglichkeiten zur Folge, wäre aber doppelter oder
dreifacher Aufwand.

T.M.

[1] mindestens "numeric" (vielleicht sogar "double" und "int") sowie
"text" und einen Typ für Blutdruck

[Marcel Bensch]

Es mu sicher mehrere collections von einem device geben k nnen, also
1:n, n mlich f r verschiedene Zwecke. Ich unterscheide bei mir
beispielsweise regul re Messungen (fr h, mittags, abends und sp t) und
Experimentalmessungen (z.B. beim Sport oder mal nach dem Essen oder
nachts), die aber alle von ein und demselben Ger t kommen.

Für dein spezielles Beispiel jetzt eine neue Collection anzulegen
halte ich für weniger sinnvoll.
Ich würde das eher in der Collection "BZ-Werte" auflisten und
stattdessen für jedes Item noch eine Subnode "itemabnormalflag" (In
Anlehnung an den ASTM E-1394 Standard) einführen.
Hier könnte dann ein Indikator stehen für pre-prandial, post-prandial,
sport, krank, kalibration etc.

Auch für die anderen Geräte ist das sicherlich sinnvoll, da es solche
"Spezialfälle" ja auch z.b. beim Blutdruck geben kann.

Eine 1:n Beziehung sehe ich trotzdem als nötig wenn man zum Beispiel
bei der Pumpe noch
Sachen wie Fehlermeldungen, Ampulen-/ Katheterwechsel, BR-
Verschiebungen etc. auslesen will.
Werde mein Proposal dahingehen noch erweitern.

Den items in einer collection w rde ich keine id geben. Sie ist
schlicht nicht notwendig und wird sehr wahrscheinlich auch nirgends
weiter verwendet, insbesondere nicht in einer Datenbank, denn das
w rde erzwingen, da diese ids ber alle XML-Dateien hinweg eindeutig
schaffe keine k nstlichen Schl ssel, wo nat rliche ausreichend sind.

Ja auch wieder wahr ;-)

Die collection id w rde ich als string auslegen, "Blutzucker" oder
"Blutdruck" oder "0". Oder die collection m te ein name-Attribut
bekommen. Irgendetwas lesbares jedenfalls. Das ist insbesondere
wichtig, wenn man mehrere collections von einem device hat und wissen
will, worin die sich nun unterscheiden.

name-Attribut finde ich besser. IDs sollten IMHO immer numerische
Indizes sein.

Wenn auch der Wert (value) in einem item "bin r" gespeichert wird, ich
meine nicht als string, dann wird allerdings f r jeden Datentyp [1]
ein eigenes item erforderlich, z.B. ein numeric_item, wahrscheinlich
dann auch eine numeric_collection. Das h tte bessere
Validierungsm glichkeiten zur Folge, w re aber doppelter oder
dreifacher Aufwand.

Ich glaube hier stimmt Aufwand/Nutzen dann nicht mehr und solche
spezifischen Fälle kann
man ja in der letztendlichen Software dann abarbeiten. Letztendlich
sehe ich die XML ja nur
als besser lesbares und vor allem besser zu parsendes RAW-Format.

Grüße,

Marcel

[Anja Länge]

Post by Torsten Mueller
(Ich betrachte bislang auch
die Einheit als Konstante und würde, wenn ich das Meßgerät wechsle und
in einer neuen Einheit messe, auch eine neue Meßreihe beginnen.)

Das machen einige halt täglich... ein Gerät fürs Büro, ein kleines für die
Handtasche, eines für zuhause... Vielleicht macht man auch mal
Kontrollmessungen mit einem zweiten Gerät, wenn ein Wert unplausibel
erscheint und weil die Uhrzeit keine Sekunden speichert und die Geräte nicht
nach Atmzeit gehen, haben die Werte dann dieselbe Zeit...

Post by Torsten Mueller
Ich
denke an ein alltagstaugliches Programm, nicht an Laboruntersuchungen.

Eben ;)


Anja