[Llarian]

Da könnte man dann noch eine komplette Krankengeschichte führen, mit Erkrankungen, KH-Aufenthalten usw. (Ich werd wohl mal einen VB-Kurs belegen müssen...)

Nur sehe ich da beim derzeitigen Datenformat Probleme. Spontan fällt mir die Möglichkeit ein, beim Datentyp KRH-Aufenthalt einen zusammengesetzten Eintrag beim Wert zu erzeugen. Ein AddIn, das für die Handhabung solcher Einträge geschrieben ist, könnte das dann auch entsprechend wieder auseinanderdröseln. Schöner wärs dann gewesen, gleich auf XML-Basis arbeiten zu können. Dann wäre so ein Eintrag beliebig erweiterbar und man könnte auch Befunde und Diagnostik ablegen... wenn man also in einem Datenverzeichnis gleich die Dicom-Dateien vom Radiologen dazulegt.
Oder man erzeugt nur einen Eintrag KRH-Aufenthalt mit einer ID und nimmt sich die zugehörigen Details ein eigens Datenformat auf XML-Basis, dann muß man keine Krücken ins andere Format bauen.

Grüße
Anja

[Joerg Moeller]

Oder man erzeugt nur einen Eintrag KRH-Aufenthalt mit einer ID und nimmt sich die zugehörigen Details ein eigens Datenformat auf XML-Basis, dann muß man keine Krücken ins andere Format bauen.

Das schwebt mir sowieso eher vor. Ob jetzt XML oder ein anderes Format (dazu fehlr mir die Kompentenz das beurteilen zu können); aber getrennte Datenfiles

[Llarian]

Oder man erzeugt nur einen Eintrag KRH-Aufenthalt mit einer ID und nimmt sich die zugehörigen Details ein eigens Datenformat auf XML-Basis, dann muß man keine Krücken ins andere Format bauen.

Das schwebt mir sowieso eher vor. Ob jetzt XML oder ein anderes Format (dazu fehlr mir die Kompentenz das beurteilen zu können); aber getrennte Datenfiles

XML bietet den Vorteil, nicht starr zu sein. Stell Dir eine Datenbank mit Büchern vor. In einer normalen hast Du eine Spalte für Titel, eine für Autor, Verlag, ISBN usw. Schwierig wirds dann, wenn ein Buch mehrere Autoren hat... alle in eine Spalte? Dann kann man nicht richtig sortieren, mehrere Autoren-Spalten? Aber wieviele? Verknüpfte Autoren-Tabelle? Bei XML kann man schlicht beliebig viele Autoren-Einträge für ein Buch erstellen... macht z.B. auch der Amazon-Webservice so.
btw: Bevor Du anfängst, etwas zu tippen: Bau Dir vorher das Datenmodell... Was soll in einem Eintrag enthalten sein... Aufnahmedatum, Name des Krankenhauses, Aufenthaltsdauer, behandelnde Ärzte, gefahrene Diagnostik, gefahrene Therapien, jeweils von welchem Arzt, unter welchem Pfad sind Kopien der Befunde, welche Laborwerte wurden erhoben... Da ist dann wieder ein auf SQL aufsetzendes Datenformat schick, weil man mit der entsprechenden Abfrage die hierarchischen Daten aus diversen Tabllen in eine Ausgabe zusammenführen kann.

Wie wärs mit einem eigenen Thread zum Anamnsese-AddIn?

Grüße
Anja

[breschdlingsgsaelz]

Schöner wärs dann gewesen, gleich auf XML-Basis arbeiten zu können.

Oh, ich dachte der Lobgesang auf XML wäre mein Part gewesen. Im Ernst: ein XML basierendes Datenformat wäre für Sidiary ideal. Es bietet unter anderem den Vorteil, beliebig erweiterbar zu sein ohne Kompatibilitätsprobleme (d.h. man könnte neue Daten auch mit alten Programmen verarbeiten und müsste so z.B. nicht PPC und PC-Versionen "in sync" halten). Ausserdem könnte sich jeder evtl. Abfragen die in Sidiary selbst nicht implementiert sind, per XPath zusammenbasteln und müsste nicht hunderte Megabyte Entwicklungsumgebung installieren und sich in nochmal eine API reinfuchsen, die man für nix anderes braucht. Auswertungen könnten per XSLT passieren, ohne dass man sündteure Word- und Excel-Programme kaufen (oder raubkopieren) müsste. Nuja, man darf ja noch träumen.

Wäre gerne bereit ein entsprechendes Schema oder eine DTD zu diskutieren. SQL ist bei den Datenmengen, die man so für eigene Zwecke generieren kann IMHO nicht notwendig. Vielleicht wirds ja was mit nem XML Format für Sidiary 7...

[Joerg Moeller]

btw: Bevor Du anfängst, etwas zu tippen:

Soweit bin ich bei weitem noch nicht...

Bau Dir vorher das Datenmodell... Was soll in einem Eintrag enthalten sein... Aufnahmedatum, Name des Krankenhauses, Aufenthaltsdauer, behandelnde Ärzte, gefahrene Diagnostik, gefahrene Therapien, jeweils von welchem Arzt, unter welchem Pfad sind Kopien der Befunde, welche Laborwerte wurden erhoben...

Und das wäre mir persönlich ein bißchen zu viel. Ich kenne Anamnese-Bögen aus dem KH und so wie die aufgebaut sind ist es völlig ausreichend. Ich hab sowas ja auch schon als Eigenanamnese als Word-Dokument gespeichert (und das wird dann bei Bedarf einfach ergänzt). Mehr nicht. Ich muß keine Abfragen durchführen und dabei nach Körbchengröße der Stationsschwester filtern können

Wie wärs mit einem eigenen Thread zum Anamnsese-AddIn?

Wie gesagt: wäre noch zu früh. Aber du hast mich dadurch auf eine Idee gebracht: Wenn die V6 raus ist machen wir ein Extra AddIn-Board auf. Da könnte man dann schreiben, welches AddIn einem vorschwebt, sich Anregungen holen und bei Problemen vielleicht Tips von Leuten kriegen, die sich besser mit der jeweils verwendeten Programmiersprache auskennen. Quasi die AddInns als OpenSource-Komponente von SiDiary.

[Llarian]

Bau Dir vorher das Datenmodell... Was soll in einem Eintrag enthalten sein... Aufnahmedatum, Name des Krankenhauses, Aufenthaltsdauer, behandelnde Ärzte, gefahrene Diagnostik, gefahrene Therapien, jeweils von welchem Arzt, unter welchem Pfad sind Kopien der Befunde, welche Laborwerte wurden erhoben...

Und das wäre mir persönlich ein bißchen zu viel. Ich kenne Anamnese-Bögen aus dem KH und so wie die aufgebaut sind ist es völlig ausreichend. Ich hab sowas ja auch schon als Eigenanamnese als Word-Dokument gespeichert (und das wird dann bei Bedarf einfach ergänzt). Mehr nicht. Ich muß keine Abfragen durchführen und dabei nach Körbchengröße der Stationsschwester filtern können

Für letzteres würde ich auch eine andere tagebuchform vorschlagen als ausgerechnet SiDiary...
Aber schieb die Sache mit den Abfragen mal noch nicht so ganz weg. Wenn das Datenformat beliebig erweiterbar ist und prinzipiell alles enthält, ist es halt nur eine Frage, wie man die Abfrage gestaltet, in welcher detailtiefe und Gliederung man die Ergebnisse präsentiert bekommt. So ein "offenes" Datenformat ist dann bei jeder neuen Situation erweiter- und anpaßbar. Und genauso wie man mit dem Datenmaterial entweder ein einfaches TB mit BZ-Einträgen für morgens, mittags, abends, nachts aber eben auch eine Howorka- oder Teupe-Ansicht erstellen kann, kann man dann z.B. bei einer Anamnese bei Bedarf verschiedene Detailstufen erreichen... und z.B. chronologisch die KRH-Aufenthalte listen oder nach Indikation... und wenn jemand wissen will "was war denn da?" - dann klickt er halt drauf und weiß es.

Grüße
Anja

[Joerg Moeller]

Aber schieb die Sache mit den Abfragen mal noch nicht so ganz weg. Wenn das Datenformat beliebig erweiterbar ist...

Da stimme ich dir völlig zu. Besonders wenn es um OpenSource geht sollte das Datenformat so universell wie möglich sein. Allein schon, damit die Daten vielleicht auch mal in anderen Projekten verfügbar sein können (Warum das Rad zweimal erfinden?)

[LordBritish]

So als kleiner Tipp am Rande bezüglich AddIn, zwar ist das Buch noch nicht erschienen soll aber Ende Septemmber 2008 erscheinen.

Add-In-Entwicklung für Visual Studio 2008

ISBN-10: 3939084182
ISBN-13: 978-3939084181


Grüße

Markus

[Llarian]

So als kleiner Tipp am Rande bezüglich AddIn, zwar ist das Buch noch nicht erschienen soll aber Ende Septemmber 2008 erscheinen.

Add-In-Entwicklung für Visual Studio 2008

Da gehts um AddIns für Visual Studio... nicht mit Visual Studio. Sprcih, das Visual Studio selbst kann angepaßt werden.

Grüße
Anja

[Llarian]

Da stimme ich dir völlig zu. Besonders wenn es um OpenSource geht sollte das Datenformat so universell wie möglich sein. Allein schon, damit die Daten vielleicht auch mal in anderen Projekten verfügbar sein können (Warum das Rad zweimal erfinden?)

Warum wird diese Philosophie dann nicht in der V6 gepflegt?

Grüße
Anja