Database attività chirurgica
maxgeg
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
Andrea D'Amore
<01d55baf-3556-447f...@c10g2000yqi.googlegroups.com>,
maxgeg <maximili...@gmail.com> wrote:
> Ciao a tutti,
[CUT]
> Sulla base dii queste informazioni spero che qualcuno di voi possa
> 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.
^_Goblin_^
> Ciao a tutti,
> sono nuovo e poco pratico di database...ho già cercato nelle varie faq
> ma non ho trovato risposta al mio dilemma!
> 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
Manlio Perillo
> Il 14/08/2010 15.24, maxgeg ha scritto:
>> Ciao a tutti,
>> sono nuovo e poco pratico di database...ho già cercato nelle varie faq
>> ma non ho trovato risposta al mio dilemma!
> MEGACUT :)
>> Grazie in anticipo della collaborazione
>
> [...] 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
Attenzione che Access è un frontend, **non** un database.
Access può essere collegato senza problemi a database come PostgreSQL e
altri.
Ciao Manlio
Pietro66
prospettate dall'OP, soprattutto come volumi di dati, andrebbe benissimo
IMHO, anche per gli archivi.
ciao
Manlio Perillo
> [...]
>> 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,
Ripeto che Access è un frontend, che di default si appoggia a Jet, un
database engine file based.
> e per le esigenze
> prospettate dall'OP, soprattutto come volumi di dati, andrebbe benissimo
> IMHO, anche per gli archivi.
>
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
Gufo Rosso
> 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
> 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
> ...
sourceforge.net trovi dei db clinci usati negli usa
come chiave di ricerca metti salute in inglese
>
> 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
c'e' tante soluzioni al problema....
Hermooz
> 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.
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!
maxgeg
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...
ValeRyo Saeba
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
ValeRyo Saeba
news:i4bpd7$h4d$1...@alix.livenet.it
> "maxgeg" <maximili...@gmail.com> ha scritto nel messaggio
> news:d6367f6c-bd65-470e...@w30g2000yqw.googlegroups.com
>> 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...
>
> 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.
'Se poi il tutto lo vedi in...'
vittorio
> Ripeto che Access è un frontend, che di default si appoggia a Jet, un
> 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.
The man with two watches
>> Ripeto che Access è un frontend, che di default si appoggia a
>> Jet, un database engine file based.
>
> 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.
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.
Andrea [Work]
> 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
> ...
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.
leon...@libero.it
> 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