Ich lade bei Dir ein allgemeines Problem ab, das mich schon lange ärgert. Aber wahrscheinlich bin ich, wie meistens, wieder einmal zu wenig chaostolerant, was ganz und gar nicht in die heutigen Chaos-Zeiten passt. Die Chaosintoleranz ist halt einmal ein wesentlicher Bestandteil einer Programmierer-Seele.
Das Problem: mg% oder SI-Einheiten mmol/l ! Ich erinnere mich noch gut an die frühen 80er-Jahre, als gegen den Widerstand und zum Ärger der Praktiker in der Schweiz, so obrigkeitsgläubig und anpasserisch wie immer, von oben herab die SI-Einheiten durchgezwängt wurden ! Heute, wo ich vermehrt alles hinterfrage, frage ich wieder: wozu eigentlich?! Da wo die bedeutenden epidemiologischen Arbeiten geschrieben werden und wohin unser aller Augen sich richten, nämlich in USA und in UK rechnet man heute noch in den alten Einheiten mg% !!!
Die entscheidende Frage: in welchen Einheiten rechneten die Statistiker, die den FRC-Score kreiert haben? in mg% oder in mmol/l?
In der Originalarbeit primprev.pdf beschreibt Scott M.Grundy in Table2 den "Scoring for Global Risk Assessment (Adjusted Framingham Scoring)" und verwendet als Gruppengrenzwerte die Masseinheiten mg% (entsprechend Original-USA). Rechnen wir diese Werte um in die SI-Einheiten mmol/l, so müssen wir uns genau überlegen, wie wir das tun (vergl. dazu die Tafel unten). Hat Grundy jedoch eine Originalarbeit, die mmol/l verwendet, in mg% umgerechnet, so erübrigen sich meine Überlegungen und wir verwenden einfach die Original-SI-Einheiten mmol/l für unsere IF-Kaskade.
| TC mg% MM 38.666 | CUT mmol/l | CUT IF-Kaskade | ROUND mmol/l | ROUND IF-Kaskade | Romenens IF-Kaskade |
|---|---|---|---|---|---|
| >=280 | >=7.25(280.33) | > 7.24 | >= 7.23(279.56) | > 7.22 | > 7.23 |
| 240-279 | 6.21(240.12)-7.24(279.94) | < 7.25 | 6.20(239.73)-7.22(279.17) | < 7.23 | < 7.24 |
| 200-239 | 5.18(200.29)-6.20(239.73) | < 6.21 | 5.15(199.52)-6.19(239.34) | < 6.20 | < 6.20 |
| 160-199 | 4.14(160.08)-5.17(199.90) | < 5.18 | 4.13(159.69)-5.14(198.74) | < 5.15 | < 5.15 |
| < 160 | <= 4.13(159.69) | < 4.14 | <= 4.12(159.30) | < 4.13 | < 4.14 |
| mg/dl | mmol/l (mg/dl) | mmol/l | mmol/l (mg/dl) | mmol/l | mmol/l |
| HDL mg% MM 38.666 | CUT mmol/l | CUT IF-Kaskade | ROUND mmol/l | ROUND IF-Kaskade | Romenens IF-Kaskade |
|---|---|---|---|---|---|
| >=60 | >=1.56(60.32) | > 1.55 | >= 1.54(59.55) | > 1.53 | > 1.54 |
| 50-59 | 1.30(50.27)-1.55(59.93) | < 1.56 | 1.29(49.88)-1.53(59.16) | < 1.54 | < 1.55 |
| 45-49 | 1.17(45.24)-1.29(49.88) | < 1.30 | 1.16(44.85)-1.28(49.49) | < 1.29 | < 1.30 |
| 35-44 | 0.91(35.19)-1.16(44.85) | < 1.17 | 0.90(34.80)-1.15(44.47) | < 1.16 | < 1.17 |
| < 35 | <= 0.90(34.80) | < 0.91 | <= 0.89(34.41) | < 0.90 | < 0.89 |
| mg/dl | mmol/l (mg/dl) | mmol/l | mmol/l (mg/dl) | mmol/l | mmol/l |
| PlGluc mg% MM 18.016 | CUT mmol/l | CUT IF-Kaskade | ROUND mmol/l | ROUND IF-Kaskade | Romenens IF-Kaskade |
|---|---|---|---|---|---|
| > 126 | >=7.00(126.11) | > 6.99 | >=7.00(126.11) | > 6.99 | > 7.00 |
| 110-126 | 6.11(110.08)-6.99(125.93) | < 7.00 | 6.08(109.54)-6.99(125.93) | < 7.00 | < 7.00 |
| < 110 | <= 6.10(109.90) | < 6.11 | <= 6.07(109.36) | < 6.08 | < 6.10 |
| mg/dl | mmol/l (mg/dl) | mmol/l | mmol/l (mg/dl) | mmol/l | mmol/l |
Die Wahl der IF-Kaskaden, die unserem Programm zugrunde liegen soll, überlasse ich Dir. Ich würde die CUT-IF-Kaskade bevorzugen, da vermutlich die originale Gruppeneinteilung aufgrund von CUT-Werten und nicht aufgrund von ROUND-Werten vorgenommen wurde.
Keinesfalls sollte man jedoch in der gleichen IF-Kaskade einmal CUT-Grenzwerte und einmal ROUND-Grenzwerte vermischen ! Unser JAVAScript bedarf also so oder so einer entsprechenden Korrektur ! In Minne liesse sich das Problem lösen, wenn die dem FRC-Score zugrunde liegenden Original-Berechnungen in mmol/l erfolgt sind. In diesem Fall nehmen wir einfach diese Werte und alle andern haben eben unsauber in mg% umgerechnet.
Ich werde die Grenzwerte auch noch für die andern Grenzwerte berechnen. Wichtig scheint mir dabei, dass man zur Berechnung den 3-dezimalstelligen Wert der Molekülmasse benutzt, womit man immer gleichartig hin & her rechnet ( mit "*" & "/" Operator) und nicht einfach für die Umkehrrechnung einen gerundetet reziproken MM verwendet, mit welchem man dann einfachheitshalber multipliziert (eine weitere Unsitte, die oft angewandt wird und nur weitere Fehlerquellen produziert !!)
Alles in allem, denke ich, dass mein Ärger mit dem Einheiten-Wirrwarr schon ein bisschen berechtigt ist.
Herzliche Grüsse,
Programmierungs-Dokument 16/18.6.2002 Franz
17.6.2002: Antwort des Programmleiters Romanens: Die Originalarbeit erfolgte in den Einheiten mg/dl, Entscheid für CUT-IF-Kaskade für den Programm-Einsatz