Moin,

ich arbeite seit einiger Zeit daran, für Patienten eine Datei zu erstellen, in die Meßwerte eingetragen, gespeichert, ausgewertet und im Diagramm ausgedruckt werden können.

Der Hintergrund dazu ist, daß ambulante, oder gar stationäre "Überwachungen" nicht, oder nur sehr selten stattfinden (meistens erst dann, wenn es zu spät ist) und daß es daher für unsere Patienten notwendig ist, mehrmals täglich z.B. ihren Blutzuckerspiegel zu messen und diese Werte zu dokumentieren.

Dazu kommen noch weitere Werte, wie z.B. Urinzucker, Blutdruck, Puls, HbA1C, Körpergröße, Gewicht, Fettanteil, Wasseranteil, Muskelanteil, Knochengewicht...

Je mehr, desto besser, denn je mehr Werte der Patient selber kennt, desto besser kann er sich selbst darauf einstellen und der behandelnde Arzt kann dadurch natürlich die Therapie des Patienten noch besser anpassen...es muß ja nicht immer ein Skalpell sein, was in einem Patienten vergessen wird...



Also habe ich mal im "Selbstversuch" eine Excel-Datei gebastelt.

Wie sie aussieht, habe ich Euch in der Anlage beigefügt.

Die Bilder 1 und 2 zeigen den aktuellen Inhaltsstand, mit all den abzufragenden, einzugebenden, zu berechnenden Werten.

Die Bilder 3 und 4 zeigen mal ein wenig, wieviele Rechenoperationen momentan schon ausgeführt werden.



Wie Ihr seht, arbeite ich schon eine Weile daran, da nur das Wochenende zur Verfügung steht.

Jetzt habe ich aber alle Daten, die ich benötige und auch die Berechnungen funktionieren einwandfrei, denn für bestimmte Aussagen, oder Trendangaben müssen mehrere Faktoren miteinander in Beziehung gesetzt werden (Bsp.: Mann/Frau - Alter 0-3 - Alter 4-7 - Alter 8-13 - Alter 14-17 - Alter 18-25 - Alter 26-45 - Alter 46-60 - Alter 61-75 - Alter über 75 - Körpergröße - Körpergewicht - Körper-Fettanteil, Körper-Wasseranteil, Dialysepatient ja/nein ...)

Bestimmte Werte bedingen sich gegenseitig und das habe ich auch in diese Excel-Datei mit einfließen lassen.





So weit, so gut; nun kommen wir aber zum eigentlichen Thema!

Ich wollte diese Datei gerne den Patienten mit nach Hause geben, oder in der Praxis "laufen" lassen, ABER ...

... nicht jeder hat Excel UND schon mit meinen paar Testeingaben für drei, vier Monate "keucht" der Rechner, schließlich werden pro Arbeitsblatt (also pro Monat) etwa 120 Rechenoperationen im Hintergrund abgefragt (Name, Alter, Mann, Frau...)

und zusätzlich noch mal etwa 80 pro eingetragenen Werten eines jeden Tages

-Uhrzeit

-Wert zu niedrig, optimal, zu hoch

-wie steht der Wert in Verbindung zu den anderen Werten der 1. Tageshälfte, der 2 Tageshälfte, des Tages insgesamt und des Vortages

-Auswertung des aktuellen Monats mit dem Vormonat

-Trendanzeige

-Jahres-Bilanzdiagramm

u.s.w. u.s.f.



Ich habe schon gemerkt, daß hinter der nun vor mir stehenden Aufgabe, ein Programm zu basteln, was schnell und zuverlässig läuft, was problemlos jedem Patienten mitgegeben werden kann (SICHER, keine Viren , eventuell sogar Plattformunabhängig?!?!?), was eine "Multi-Nutzer-Möglichkeit bietet (also jeder Patient meldet sich im "Patienten-Rechner" der Praxis mit Name und Kennwort an und kann dann auch nur seine Daten sehen, teilweise ändern, ausdrucken u.s.w.) und was sich auch noch schnell am Wochenende perfekt programmieren läßt , wohl doch etwas groß dimensioniert ist, um sie mal eben so nebenbei zu bewerkstelligen. (Nach der ersten Idee mit nur zwei Meßwerten, kamen weitere Ideen, dies und das doch auch noch dazu zu nehmen...wie im Garten...man wird nie fertig... )



Aber dennoch habe ich mich noch nicht von dieser Idee gelöst und wollte erst mal "klein" Anfangen.

Also wichtig wäre momentan folgende Funktionsweise:

-Benutzer meldet sich am System an (Name, Kennwort)

-ist Name bereits vorhanden, dann anderen Namen wählen (Heino2, oder Heino3...vielleicht kann sogar das Programm dies vorschlagen?)

-ist Name frei und Kennwort i.O., erfolgt die Anmeldung

-Admin-Zugang wäre sinnvoll, oder vielleicht auch "Notfall-Frage", falls jemand sein Kennwort vergißt

-nun kann der Patient mit Name und Kennwort seine eigenen Daten eingeben (Name, Adresse, Medikation, Besonderheiten.......)

-nun kann der Patient einen Tag aus dem Kalender aufrufen, oder manuell ein Datum eingeben, und dann wird eine Maske geöffnet, in die er seine Meßwerte eingibt (Blutzucker, Gewicht, Körper-Fettanteil.....), in die er aber auch Besonderheiten eingibt (z.B. heute Marathon gelaufen, gestern Triathlon gemacht...)

-wenn die Eingabe gespeichert ist, kann er sich eine Art Tages-, Wochen-, Monats-, oder Jahresübersicht (Jahrzehnteübersicht...) anzeigen lassen, wenn nicht gleich mit angezeigten Tendenzen (gleichbleibend, steigend, fallend, besser werdend, schlechter werdend...) und Vergleichsanzeigen zum Vortag, zur Vorwoche, zum Vorjahr... dann doch wenigstens mit den reinen Werten der Eingaben in einer hübsch gegliederten Übersicht

-später kann man ja noch mal darüber nachdenken, eventuell "Updates" von Daten des Patienten-Rechners, über "USB-Stick" auf das Patienten-Konto des Praxis-Rechners einspielen zu lassen, oder sogar einen "Online-Zugang" für die Patienten einzurichten

-aber wichtig wäre erst mal, daß sich der Patient, oder zwei Patienten (Ehepaar) selbständig zu Haus "begutachten" können





Nun dachte ich daran, das ganze mit VB und SQL zu lösen.

Ich kenne mich z.B. (recht) gut mit VB Script, VB 2010, .xml, CSS, Java, oder JavaScript aus.

Ich bin sicher kein Experte, aber auch kein unbeschriebenes Blatt.

Ich erkenne die Strukturen und weiß, was passiert, wenn ich dies, oder jenes verändere.

Ihr habt es also bei Euren Hilfestellungen mit keinem 'kompletten' Dödel zu tun.

Ich hatte also an VB und SQL gedacht, denn da bräuchte der Rechner die Einzelwerte und die Beziehungen ja erst nach dem speichern, quasi in einem Abwasch berechnen und nicht wie jetzt, bei jeder Eingabe eines Wertes; oder?

Evtl. kann es auch VB und Access sein?

Oder doch VB und Excel?

Aber dann rechnet der Rechner ja wieder so lange...

In jedem Fall sollte es möglichst klein, robust und sicher sein und auch schnell laufen. (Liegt natürlich im Auge des Betrachters...)



Tja, nun ist guter Rat teuer.

Womit setze ich es am besten um?

Was ist am effektivsten zu tun?

Was würdet Ihr vorschlagen?

Als erfahrener Programmierer habt ihr sicherlich schnellere und umfangreichere Lösungen bei der Hand, als ein Wochenend-Programmeintipper.

Ich bin für jede konstruktive Kritik und/oder Anregung/Hilfestellung/Beispielzeichnung dankbar!




:!: BITTE NUR EINS NOCH...nachdem ich schon etwas durch dieses Forum geforscht habe und hier und da schon den einen, oder anderen "Experten und (Alles)Könner" gesehen habe...

...wem es nicht gefällt, der kann sich gerne zu Hause darüber auslassen, meinetwegen die ganze Nacht lang,...

...aber BITTE verhunzt doch nicht dieses schöne Forum mit einsilbigen, ideenlosen, oder beleidigenden platz- und zeitraubenden Schwafeleien...

...à la...

"wer braucht so was?"

"kuck ma googel" <-- interessante Schreibweise, aber tatsächlich hier so gesehen...

"steht hier iwo im Forum"

"könnt ich besser" (tatsächlich?...wie?...mach!...gib Hilfe!...dafür sind wir doch hier, um Hilfe zu suchen, oder zu geben...in der Zeit, in welcher Du die obigen vier Antworten hingesch...leudert hast, hättest Du auch etwas sinnvolles, lösungsorientiertes, also hilfreiches schreiben können!)


Es ist für einen Rat- und Hilfesuchenden ebenso nervig, wie für jemanden, der sich ernsthafte Gedanken um Lösungen macht, wenn er erst mal zwei, drei Seiten weiterblättern muß, um, nach all den niedergeschriebenen geistigen Flatulenzen, mal wieder etwas konstruktives und Geist anregendes zu lesen.

VIELEN DANK!

Also gut ... auch wenn ich jetzt nicht alles verstanden habe, hier mal ein paar Anmerkungen von mir:

1. Sowas ist kein Ding für ein Excel-Sheet, das ist eine reine Datenbankaufgabe ... daher richtige Überlegung das mit einer Datenbank im Hintergrund zu erledigen.

2. Wie mächtig und aufwändig hättest Du es denn gerne? Einen SQL-Server einzurichten und am besten gleich noch übers Internet verfügbar machen damit die Patienten direkt von zu Hause ihre Daten eingeben können ist natürlich schon eine etwas komplexere Geschichte.

3. Ich vermute Du hast vielfach mit Patienten zu tun die keinen PC besitzen. Ich würde mir hier eine Datenerfassung überlegen die für jeden verfügbar und umsetzbar ist. Willst Du wirklich auf Erfassung per PC setzen, würde ich folgenden Weg vorschlagen:

- Nutzung von typisierten DataSets oder ADODB.Recordsets, beides Möglichkeiten Daten wie in einer Datenbank zu erfassen und zu verwalten aber eben ohne die zwingende Notwendigkeit wirklich eine DBMS im Hintergrund zu haben ... beide Formen lassen die Speicherung der Dateninhalte in einer XML zu.

Dazu bastelst Du eine nette kleine NET-Anwendung die dem Nutzer die Erfassung der Daten ermöglicht und im Hintergrund alle erfassten Daten eben dann nicht in eine DB sondern als XML abspeichert.

Dazu dann noch eine Funktion Daten per Email versenden einbasteln und damit lässt Du Dir die beim Patienten erstellten XML's zu senden. Der Vorteil ist, diese XML's kannst Du problemlos einlesen und direkt ohne Nachbearbeitung in Deine Datenbank in der Praxis übernehmen und nun die Daten frei nach Belieben auswerten.

In der Anwendung die Du dann in Deiner Praxis laufen hast sollte natürlich schon eine echte Datenbank dahinter stehen.

Vorteil dieser Vorgehensweise:

- kein SQL-Server notwendig, ein einfaches Single-File-DBMS wie z.B. Access reicht völlig aus
- einfachste und unkomplizierte Weitergabe des Programmes an alle Patienten ohne Dir einen Kopf über die Zugriffsregelungen machen zu müssen, auf dem Rechner daheim hat er eh nur seine Daten und kann diese auswerten und auf die Datenbank die Du vorhälst zur Sammelung aller Daten hat er eh keinen Zugriff ... sicherer geht es nicht mehr (vielleicht dem Patienten die Patientennummer mitgeben und die muss er dann im Programm bei sich daheim eintragen?)
- sowas kann man völlig systemunabhängig gestalten
- späteres Aufbohren auf Internet gestützen SQL-Server ist problemlos möglich, es müssen ja nur die zugriffe von XML auf DB-Connection umgestellt werden
- der Patient kann auch ohne aktive Internetverbindung seine Daten eingeben
- das kann man sogar auf Smartphones portieren

Meiner Meinung nach wäre das für Dich der optimalste Weg und vor allem einer bei dem Du keinen irren Aufwand betreiben musst und vermutlich auch selber umsetzen kannst.

Gruß

Rainer

Hi.

Eine Anmerkung von mir: Produziere auf keinen Fall ein System, mit dem die Patienten ihre Daten übers Internet in eine zentrale Datenbank schreiben können. Da du eine .NET-Anwendung bastelst, kann diese von jedem Benutzer dekompiliert werden. Dort findet er dann die Adresse der Datenbank und kann alle Daten absaugen, sofern du kein _sehr_ ausgefeiltes Rechtemanagement einsetzt. Da sowas sehr viel Wartungsaufwand erfordert, sind Fehler in der Bedienung / Administration vorprogrammiert.

XML-Dateien als Zwischenspeicher bei Patienten sind in Ordnung - je einfacher, desto besser. ABER: Achte darauf, die Dateien niemals unverschlüsselt zu senden. Ich bin kein Datenschutzexperte, aber Angaben, die normalerweise der ärztlichen Schweigepflicht unterliegen, sollten nicht einfach per Mail verschickt werden. Dafür bietet sich ein Server mit gesichterter Uploadfunktion an. Dabei solltest du wieder die Direktverbindung zur Datenbank vermeiden, sprich nicht alles, was hochgeladen wird, ungeprüft in die Datenbank zu schreiben oder gar eine Online-Eingabemaske.

Mein Designvorschlag:
- Server mit Datenbank und Uploadfunktion für Dateien (z.B. ein Standard-LAMP-System)
- Webanwendung, die den Upload entgegennimmt, sollte die Benutzer vorher authentifizieren (sie entschlüsselt die Dateien, prüft die Inhalte und trägt sie in die DB ein).
--> Alternative: Der Server nimmt nur die verschlüsselte Datei entgegen. Diese müssen dann von einer Person "abgeholt" werden - das verstärkt nochmal die Sicherheit, da so keine Patientendaten unverschlüsselt auf dem Server liegen.
- .NET-Clientanwendung, die du an die Patienten verteilst, fragt Messwerte ab
--> Werte werden in XML-Datei(en) gespeichert
--> Button "Export" erstellt eine verschlüsselte Datei, die der Patient über das obige Webinterface hochladen kann (mit GPG - verteile deinen Public Key an die Patienten)

Du kannst sogar deine Excel-Datei, die du schon hast, weiterverwenden:
- Excel-Datei in der Arztpraxis sorgt für die Visualisierung der Messwerte aus der Datenbank

Vorteile:
- Einfach zu implementieren - Form im Designer zusammenklicken und alles in XML-Dateien schreiben
- Wiederverwendung der Excel-Datei, in der eine Menge Arbeit drinsteckt

Nachteile:
- Server muss gewartet werden
- Webanwendung und Datenbank müssen erstellt werden.

Hallo Rainer,


vielen Dank, für die wohlüberlegte Antwort.

Ich muß gestehen, aus dem ursprünglich kleinen Kind ist mittlerweile ein wahres Monster geworden.

Gerade nach dem durchforsten dieses Forums und beim verfassen dieser Anfrage ist mir erst mal so richtig bewußt geworden, wie umfangreich sich das ganze bislang schon entwickelt hat.

Nebenbei:

Ich vermute Du hast vielfach mit Patienten zu tun die keinen PC besitzen.

Na, glaub das mal nicht!

Die meisten können gut mit einem PC umgehen. Die jüngeren Patienten (und von denen gibt es immer mehr) sowieso, und die älteren sind ganz begierig darauf, etwas über die "neuen Techniken" zu erfahren und diese Technik auch selbst zu nutzen.

Es gibt, zumindest bei mir, nur ein paar "notorische Verweigerer", oder Menschen, die nun 'wirklich' zu alt sind.

Die gute Akzeptanz dieser "neuen Techniken" (sagen die älteren Damen immer zu "PC & Co.") war ja auch der ursprüngliche Grund, warum ich daran dachte, ein "kleines Gimmick" zu programmieren.

Es gibt, salopp gesagt, für jedes kleine "Weh Wehchen" eine kleine Excel-Tabelle, oder ein kleines Notizzettelchen (meist WordPad), aber es gibt halt nichts, wo alles zusammengefaßt ist, um z.B. die wichtigsten Faktoren zu erfassen, zu dokumentieren und daraufhin auswerten zu können.

Das ist quasi so, als ob Du die Karosserie von BMW hast, ein paar Felgen von VW, die Scheiben von Mercedes und die Kabelbäume von Audi.

Und nun versuchst Du, daraus irgendwie ein Auto zu basteln, weil die Einzelteile zwar jedes für sich, an seinem Platz schön sind, aber diese Einzelteile ebend doch kein "ganzes" Auto sind.

Hinzu kommt ja, daß ich bislang geplant hatte, die Daten per Hand eingeben zu lassen.

Durch die Eingabe rekapituliert der Patient noch einmal diese Werte und durch die optisch aufbereitete Anzeige (Werte gleich, besser, oder schlechter) wird ihm noch einmal anders sinnlich bewußt gemacht, auf welchem Weg er sich befindet.

Wenn man es nun ganz wild treiben wollte, könnte man ja auch noch daran denken, eine "Schnittstelle" für die Einlesung der Daten der unterschiedlichen Meßgeräte (und da hat natürlich auch jeder Hersteller sein eigenes Programm dazu und ist auch nicht bereit, mit anderen Herstellern zusammenzuarbeiten) zur Verfügung zu stellen.



Es ist halt Fluch und Segen zugleich.

Segen; weil der Patient sehr viel in eigener Hand hat, sehr flexibel ist und sehr viel selbst zum guten Verlauf seines Zusammenlebens mit seinem "lebenslangen Begleiter" tun kann.

Fluch; weil natürlich gerade durch diese Flexibilität (wenn ein Patient gut eingestellt ist und sein Leben "gut im Griff" hat, kommt er alle vier Wochen einmal zur Kontrolle und für ein Rezept vorbei) das Interesse der Wirtschaft doch etwas bescheiden ist, auch in die "neue Technik" zu investieren.





So, jetzt laß ich mir mal Deine Hinweise und Anregungen durch den Kopf gehen, wie aufwendig ich es nun wirklich betreiben will/sollte.

Ich danke Dir zunächst schon mal für die Vorschläge und Aufzeichnungen der Vorteile und der Einschränkungen.



VG von René.

Moin hal2000

Produziere auf keinen Fall ein System, mit dem die Patienten ihre Daten übers Internet in eine zentrale Datenbank schreiben können.

Ah, vielen Dank für diesen Hinweis!

Siehst Du, da habe ich mir bislang nur Gedanken gemacht, wie ich die Daten bei mir und bei den Patienten sichern kann, aber ganz außer Acht gelassen, daß natürlich auch der Datenweg vom Patienten zu mir (und zurück), bzw. die "Schaltstationen" dazwischen eine Angriffsfläche bieten.



Oh weh, ich glaube wirklich, daß ich das gesamte Projekt mal einer fachmännischen Prüfung unterziehen lassen muß, ob der Aufwand von mir allein überhaupt zu bewerkstelligen ist.

Einerseits sehe ich, daß es doch schon ein gewaltiges Vorhaben ist, andererseits zeigen mir Eure Vorschläge und Hinweise, daß es aber nicht unmöglich zu sein scheint.

Das macht mir nun wiederum Mut!

Ich denke, die Variante, die Daten in XML-Dateien zu speichern und zusenden zu lassen, ohne daß der Patient "direkten Kontakt zur Datenbank" hat ist, gerade auch da Ihr Beide solch eine Lösung als vernünftig und für diesen Fall passend anseht, wohl die beste Variante, um die Daten sicher zu transportieren.



Aber ich denke, daß ich, mit meiner "Hobby-Programmiererei", da nicht entscheidend voran komme und diesen Fall wirklich mal einem Profi in die Hand geben muß.

Wenn es im Rahmen bleibt, ist diese Investition sicherlich immer noch besser, als wenn ich es weiterhin allein versuche und am Ende nur ein unbefriedigendes und unsicheres Werk dabei herauskommt.



Ich danke Euch bislang jedoch schon mal für die bisherigen Hinweise, Einschätzungen und Erfahrungsberichte!





VG von René.

Kannst EXCEL Tabelle als Datenbaktabelle verwenden: vb.net-informations.com/excel-…_excel_2007_tutorials.htm

@Alex: Genau das sollte er gerade nicht tun. Er braucht ein schnelles und kein langsames Programm.

@Rene: Das Projekt ist groß und aufwendig. Als Wochenend-Programmeintipper (toller Begriff ) wirst du das definitiv nicht in kurzer Zeit schaffen. Je nach Erfahrung solltest du ein halbes Jahr dafür einplanen.

...dann SQL Datenbanken benutzen.

@ hal2000

Natürlich, sollten die XML-Versendung per Email nur verschlüsselt erfolgen. Keine Frage, war für mich so selbstverständlich das ich es völlig vergessen habe zu erwähnen.

Die Variante mit dem Server und Web-Uploader halte ich im Anfangsstadium einfach für zu aufwändig (Einrichtung, Kosten und Wartung) und würde meiner persönlichen Meinung nach auch keine Vorteile bringen:

Ob jetzt die Daten per Email reinkommen oder man sie sich vom Server downloaded wäre erstmal gehupfelt wie getupfelt. Server ist eher nachteilig weil man über einen Dritten geht und für dessen Verhalten seinen Kunden gegenüber verantwortlich ist (Datenverluste, Downtimes etc.). Wenn der Email-Versand nicht klappt oder dort eine Email verloren geht, dann kann der Kunde sich über seinen eigenen Provider ärgern aber kann nicht den TE dafür verantwortlich machen.

Sicherheitsvorteile sehe ich bei entsprechender Verschlüsselung der per Email versendeten XML-Datei auch nicht. Nur den Sicherheitsnachteil das bei einem Hack gleich alle dortigen Daten abgegriffen werden können. Vorallem wäre bei einem Server-Hack und entsprechenden Datenverlust der TE verantwortlich, wird eine Email abgegriffen kann der TE dafür nicht haftbar gemacht werden sofern er die Option "auf Datenträger speichern" für die Übergabe per CD/USB-Stick zusätzlich zum Email-Versand anbietet. Dann hat der Patient sich für den Versand per Email entschieden und damit ist der TE bei Datenverlust/Datenmißbrauch raus aus der Haftung (entsprechender Verschlüsselungsmechanismus der XML-Datei vorrausgesetzt).

@ SystemUnknown

Wie gesagt, SQL-Server-DB halte ich zum momentan Zeitpunkt für mit Kanonen auf Spatzen geschossen. Eine Single-File-DB wie Access oder SQLite tun den Job der hier gefordert wird gleich gut und Access ist selbst für Mutliuser-Nutzung gut ausreichend (zumindest solange es nicht über 10 User hinaus geht).

@ Rene-Spandau

Nach den Infos denke ich ich kann mir relativ gut vorstellen was Du haben willst, aber dringende Empfehlung wäre: Schritt für Schritt vorgehen.

Je nach Deinem Erfahrungsgrad würde ich als Wochendprogrammierer auch so zwischen 6 und 9 Monaten für den ersten Schritt rechnen.

Das ist quasi so, als ob Du die Karosserie von BMW hast, ein paar Felgen von VW, die Scheiben von Mercedes und die Kabelbäume von Audi.

Und nun versuchst Du, daraus irgendwie ein Auto zu basteln, weil die Einzelteile zwar jedes für sich, an seinem Platz schön sind, aber diese Einzelteile ebend doch kein "ganzes" Auto sind.

Das Problem kenne ich zur Genüge, schreibe aktuell ein CRM-Tool spezielle für den Versicherungsaußendienst da die das gleiche Problem haben ... alles ist woanders gespeichert, nichts passt zusammen und einen gesamt Überblick über den Kunden an einer Stelle ist daher völlig unmöglich.

Aber glaub mir ... sowas wird dann richtig böse aufwändig.

Wenn man es nun ganz wild treiben wollte, könnte man ja auch noch daran denken, eine "Schnittstelle" für die Einlesung der Daten der unterschiedlichen Meßgeräte (und da hat natürlich auch jeder Hersteller sein eigenes Programm dazu und ist auch nicht bereit, mit anderen Herstellern zusammenzuarbeiten) zur Verfügung zu stellen.

Wenn die Hersteller entsprechende Schnittstellen für die Auslesung von Daten aus Ihren Programmen haben, dann dürfte das aber nicht mehr das große Problem sein. Wenn eh schon alles steht (DB und Handling der Daten von den Patienten) dann ist es ja nur noch auslesen von Daten, aufbereiten und in die DB eintragen und Feierabend. Aber das hängt stark von den Schnittstellen der Hersteller ab.

Gruß

Rainer