Newsgroup: it.comp.software.database
Titolo: Database attività chirurgica

Ciao a tutti,
sono nuovo e poco pratico di database...ho già cercato nelle varie faq
ma non ho trovato risposta al mio dilemma!
Sono un chirurgo e avrei necessità di integrare l'attività clinica e
chirurgica con un database. Attualmente ogni volta che si vuole
verificare un determinato parametro "X" in modo oggettivo si è
costretti a recuperare dai registri cartacei tutti i pazienti e da lì
recuperare cartelle e spulciarle per mesi per ottenere i dati
necessari (sempre che siano presenti!) crenado un file excel da cui
poi eseguire funzioni statistiche (medie, mediane, dev standard curve
sopravvivenza T test etc) o da interfacciare ad altri programmi (come
SPSS...) per l'analisi dei dati sia per report interni o per la
pubblicazione scientifica di articoli. Ovviamente se 2 mesi dopo oltre
a valutare il paramentro X pensi che la tua analisi possa essere
inficiata anche dal parametro "Y" devi ricominciare tutto da capo...
Nella maggior parte dei Centri esteri esistono dei DB istituzionali
specifici ma purtroppo non in Italia, spt in questo periodo di
ristrettezza economica...
Ho pensato di ovviare a ciò con la creazione di un DB da aggiornare in
modo prospettico per ogni singolo paziente in base alla patologia (es
Neoplasie colon) che raccolga i dati lungo tutto il percorso da lui
effettuato e quindi suddividendo in diverse sezioni:
1. Anagrafica
2. Work up diagnostico
3. Intervento chirurgico
4. Decorso post operatorio
5. Follow up
...
Ovviamente tutti questi dati dovrebbero convergere sul foglio di excel
(Colonne: Variabili Righe: singoli pazienti) su cui poi poter
impostare una serie di funzioni e macro in modo da ottenere un report
mensile, semestrale...
MI sembra di aver capito che un punto fondamentale per la scelta del
tipo di DB sia il numero di record che deve accogliere. In merito alla
patologia portata ad esempio (es Neoplasie colon) teniamo conto che
ogni anno saranno circa 150-200 pazienti e per ogni paziente penso che
i dati da raccogliere siano intorno a 100 se non di più.
Sulla base dii queste informazioni spero che qualcuno di voi possa
aiutarmi nella scelta del tipo di DB. Quindi i vincoli che ho sono:
- Software free
- Possibilità di raccogliere i dati in un registro excel o analoghi
- Piattaforma Mac (che io utilizzo a casa) e Win (utilizzata da tutto
l'Ospedale)
- adattabilità su una rete locale anche da un numero limitato di PC
(max 10)
- Possibilità di recupero dei singoli pazienti nel tempo per
aggiornamento follow up (6 mesi 1 anno 2 anni etc etc)
- Funzione di ricerca/filtro all'interno del DB
Inoltre vi vorrei chiedere se con un DB si può creare, mediante
l'utilizzo solo di alcune variabili inserite al suo interno, un foglio
di testo. MI spiego meglio, attualmente il registro operatorio è
cartaceo su modello prestampato, dal momento che le variabili che
contiene verrebbero ad essere inserite anche nel DB (Nome Cognome
Patologia Intervento Accesso Tipo di anastomosi Struemnti etc etc)
vorrei sapere se fosse poi possibile selezionarle fare in modo di
inserire nella stampante il foglio del registro invece farlo a
mano...Questo spt perchè per riuscire a farlo utilizzare da tutto il
personale compreso quello non interessato all'analisi dei dati è
necessario snellire le procedure e non aggiungere del alvoro giudicato
da alcuni inutile o superfluo
Grazie in anticipo della collaborazione

 aiutarmi nella scelta del tipo di DB. Quindi i vincoli che ho sono:
Anzitutto complimenti per l'entusiasmo che nasce da una sana esigenza: 
lavorare più comodamente.
Il database di cui hai bisogno mi sembra modesto in quanto a dimensioni 
e dubito che una scelta o l'altra offra vantaggi significativi, a occhio 
direi che PostgreSQL o anche SQLite siano più che sufficienti.
La questione più importante è l'interfaccia tra la base di dati e 
l'utente, l'implementazione della tua base di dati passa (almeno in 
teoria) attraverso la progettazione, fase in cui si analizzano le 
richieste e le specifiche del problema, formalizzandole ed eventualmente 
raffinandole ripetendo il processo.
La questione è se vuoi fare qualcosa "in casa" o se hai un budget, nel 
secondo caso ti consiglio di affidarti ad un professionista che provvede 
a tradurre le tue richieste e le condizioni in cui lavori in termini 
formali.
L'alternativa è avviarsi a realizzare un prodotto domestico e vedere 
dove arrivi :-)
In questo senso e viste le tue richieste io consiglio una web 
application a fare da interfaccia tra l'utente e la base di dati, tutte 
le piattaforme hanno un browser, con la vista quanto più semplice 
possibile (less is more). Questo soddisfa il requisito di 
multipiattaforma e di piccola rete, inoltre si realizza facilmente con 
software disponibile gratuitamente. Per la stampa si possono creare dei 
file PDF che stampati vadano a riempire i moduli già presenti.
Riguardo la presentazione dei dati con Excel si è facile interrogare il 
database per poi esportare in CSV i dati che interessano, l'importante è 
creare un buon modello dei dati all'inizio, in modo da poter poi 
effettivamente raccogliere i dati che ti servono.
L'inconveniente è che la webapp si deve realizzare quindi ci vuole un 
minimo di conoscenza di programmazione e voglia di capire il meccanismo 
ovvero bisogna rivolgersi a qualcuno che la realizzi.
Un suggerimento ulteriore è quello di dare un'occhiata alle soluzioni 
già presenti sul mercato, dato che dici che all'estero si usano, e 
vedere se ce ne sono di disponibili nel budget (gratuite o meno) o al 
limite possono essere usate come riferimento per capire cosa deve 
offrire l'applicazione.
I miei due eurocent.

 Grazie in anticipo della collaborazione
Come ha detto andrea se avete un budget a cui far riferimento 
rivolgetevi ad un professionista oppure ad una software house 
specializzata nel campo medico che è a conoscenza di tutte le vostre 
problematiche che possono essere la gestione delle visite e del 
follow-up, la gestione dei medicinali e degli eventi avversi ect ect.
Se volete fare un prodotto "fatto in casa" dato che avete nominato excel 
direi che il DB a cui fare riferimento è Access, con access potete 
costruire semplici maschere di inserimento dati e maschere di ricerca e 
l'esportazione dei dati in excel è istantanea, io, personalmente, non 
andrei su DB SQL come Postgres, firebird, MySQL, e compagnia per il 
semplice motivo che riversare i dati da questi DB in excel risulta molto 
più complesso, e per la mole di dati non c'e' bisogno.
Goblin

 andrei su DB SQL come Postgres, firebird, MySQL, e compagnia
Attenzione che Access è un frontend, **non** un database.
Access può essere collegato senza problemi a database come PostgreSQL e 
altri.
Ciao  Manlio


Access è un database, certo non un db server, e per le esigenze 
prospettate dall'OP, soprattutto come volumi di dati, andrebbe benissimo 
IMHO, anche per gli archivi.
ciao


A quanto ho letto, Jet ha molti problemi, e se vuoi condividere l'accesso 
in rete spesso sono guai.
Meglio usare come backend un database vero come PostgreSQL ed usare Access 
come frontend.
Ciao  Manlio

 contiene verrebbero ad essere inserite anche nel DB (Nome Cognome
c'e' tante soluzioni al problema....


 chirurgica con un database.
Max, sei un chirurgo, perchè vuoi improvvisarti informatico e
reinventarti la ruota da solo?
In ambito di DB clinici c'e' ormai molta letteratura, ci sono prodotti
finiti, e ci sono molte persone che hanno il know-how necessario per
assisterti nel lavoro. Il problema è un filino più complesso dello
scegliere che DBMS usare.
Se il problema sono i fondi, proponi una collaborazione con una
facoltà universitaria di Informatica o Ingegneria, troverai facilmente
in ambito accademico chi ti fornisce mano d'opera a gratis in cambio
di qualche credito.
Per curiosità, tu cosa penseresti se leggessi su un gruppo frequentato
da chirurghi un messaggio del tipo "Ciao, sono un informatico che non
capisce molto di chirurgia, ma a mia moglia fa male la pancia e ho
deciso di farle un'appendicectomia: secondo voi è meglio che usi un
bisturi da 10 o da 20? Ah, già che ci sono, se qualcuno mi dice da
dove cominciare a tagliare mi fa un piacere..."
bye!

Grazie a tutti per i numerosi consigli...
Come consigliato da Hermooz forse il problema si fa parecchio
complesso...
proprio per questo mi sa che inizierò con access per vedere cosa
riesco a fare, da lì poi passerò a PostgreSQL...

 ha scritto nel messaggio
news:d6367f6c-bd65-470e...@w30g2000yqw.googlegroups.com

Appunto, come detto da Hermooz:
"io inizio a tagliare dall'ombelico per vedere cosa trovo, poi da lì
magari scendo verso sinistra" :-)
Seriamente: vedi se trovi qualcosa di utile già pronto.
Se poi fai il tutto è lo vedi in modalità 'hobby' allora è diverso.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 Se poi fai il tutto è lo vedi in modalità 'hobby' allora è diverso.
'Se poi il tutto lo vedi in...'


 database engine file based.
Chissà cosa ne dicono alla Microsoft che consideri così il loro prodotto :
Microsoft Access è un relational database management system che serve in 
parte a salvare dati realizzato da Microsoft, incluso nel pacchetto 
Microsoft Office Professional ed unisce il motore relazionale Microsoft Jet 
Database Engine con una interfaccia grafica.

 grafica.
Premesso che ormai le parole si stanno svuotando di significato,
dire che Access e` un database o un rdbms e` come minimo una
sottovalutazione. Purtroppo un certo modo di parlare, e di
conseguenza, di pensare, e` andato avanti per anni, ed il costo
di riparazione e`, come spesso accade, maggiore di quello
necessario a fare la cosa giusta da subito.
Access e` un completo RAD per database (form, query builder, report
designer, linguaggio VBA con relativo IDE) che puo' usare qualunque
sorgente via ODBC e OLEDB, e che solo tangenzialmente propone il
collegamento a JET (la libreria JET e` gia' installata e usata da
Windows, prima di tutto), se non hai nient'altro di installato
nel sistema (altrimenti avresti un prodotto che appena comperato
e` inusabile, il che non e` bello dal punto di vista del marketing,
specialmente se come conseguenza decidi di installare un engine
della concorrenza...).
Su Wikipedia inglese e` spiegato bene:
http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine
"Over the years, Jet has become almost synonymous with Microsoft
Access, to the extent where many people incorrectly refer to a Jet
database as an "Access database". Even Microsoft employees do this
sometimes, but this nomenclature should always be seen as incorrect.
Jet is a database and Access is a database application development
tool (database builder)."
Notare che il punto e` che JET e` il database, non Access.

 ...
Non è semplice, noi abbiamo un software simile.
Avrai innanzi tutto delle voci variabili a seconda
dell'intervento/trattamento, questo dovrà essere molto chiaro.
Poi dovrai aver ben chiaro che dati ti servono come statistica, almeno che
tu non decida di esportare i dati grezzi e poi fare tutto "a mano" con
excel.

 Grazie in anticipo della collaborazione
Cica 3 anni fa scrissi qualcosa del genere per un mio amico medico, (in 
MAaccess) se ti interessa te lo mando
Saluti
Leonardo