BMI in diabetici

lucapuccetti ha scritto:Buongiorno faccio gentile richiesta ai colleghi di una query che estragga l'ultimo body mas index inserito nei pazienti diabetici (sia identificati come codificati che come non non codificati, se possibile) l'estrazione serve per un accordo aziendale quindi è di utilità per moltissimi colleghi.

ringrazio per l'attenzione.

cordiali saluti

Luca Puccetti Pisa

Lucio Mignone ha scritto:ciao Luca,
Piccola modifica ad una vecchia query che in questo modo dovrebbe estrarre (non sono un guru dell'sql), tramite viste, l'elenco dei pazienti di qualunque età che hanno un problema aperto che contiene la stringa DIABETE, con calcolato l'ultimo valore di BMI e ne propone una sua valutazione.
Se poi vogliamo aggiungere altri criteri per pescare qualche altro diabetico non codificato, possiamo provare (es. pz che non hanno problema diabete aperto ma: con glicemia > 126, con almeno una visita diabetologica, etc.).
Provala a me pare funzionare.

Codice:

SELECT number (*) As N, cognome, nome,datanasc, codfiscale, Years(datanasc, datavisita) As eta, sesso As __sesso__,  datavisita, risults As Valore_BMI
FROM v_accertamenti a
Where accertamento Like '%BMI%' And Not Exists
(Select a1.codice FROM v_Accertamenti a1 Where a1.codice = a.codice And a1.accertamento Like '%BMI%' And a1.datavisita > a.datavisita)
And codice IN (select y.codice from v_accertamenti y where y.problema like '%diabete%')
Group By risults, cognome, nome, datanasc, codfiscale, eta, sesso, datavisita, accertamento
Order By 2, 3, 4

draleo83 ha scritto:Questa è un pò fuori dalle regole canoniche , ma funziona (almeno nel mio caso); certo... estrarre i Diabetici senza ricorrere alla codifica porta a risultati non veritieri... (nel mio caso estrae come diabetici anche un diabete insipido, un diabete renale, 3 diabetici sospetti che non avevo codificato appunto perchè non ne ero sicuro-e che poi si è dimostrato non esserlo- ecc

-------------------------------------------------

SELECT p.cognome,p.nome, p.datanasc, (year(data)-year(p.datanasc)) eta,

( SELECT Max(a.data_open) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
and a.ac_val > '' AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string( CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)) ) ) data,

( SELECT max(a.ac_val) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609' AND ac_val > '' AND a.data_open=data ) Last_BMI

FROM V_PAZIENTI p
Where EXISTS (SELECT pb.codice FROM cart_pazpbl pb WHERE pb.codice = p.codice AND pb. nome_pbl like '%diabete%' )

Order By 1, 2

draleo83 ha scritto:Francamente non trovo l’errore.

Infatti se x.dataopen fosse : 12/06/12 e x.time_last fosse : 12/06/12 10.01.43,5

La formula Cast(x.data_open As Text) restituisce regolarmente: 2012-06-12

La formula CAST(x.time_last AS TEXT) restituisce regolarmente :2012-06-12 10:01:43.500

la formula string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) restituisce

2012-06-122012-06-12 10:01:43.500000



TRATTASI COMUNQUE DI UN PERFEZIONISMO che ho voluto sperimentare (mi annoia fare sempre le stesse cose ed usare le stesse procedure):

*credo* potrebbe essere un modo più preciso per estrarre l’ultima data dell’accertamento , e per evitare che l’espressione che viene più usata allo scopo

x.data_open >a.data_open

possa mandare in tilt l’intera query (quando lo stesso accertamento è ripetuto nella stessa data può capitare che la query restituisca 0 pazienti)

Invece si potrebbe obiettare che la query non permette di scegliere il periodo da considerare per l’estrazione del BMI

Ma la richiesta del collega non parlava di periodi e quindi ho preferito esaminare tutto l’archivio

Invece se si volesse scegliere, di volta in volta il periodo da esaminare ,le 2 subquery andrebbero impostate sulle viste e non sugli archivi(come è ora). Ma si può fare facilmente (anzi la query sarebbe anche più facile)



Per quanto riguarda il tuo problema, non ho capito cosa vuoi fare. se ti spieghi meglio, insieme ai tanti colleghi esperti, si potrebbe vedere se esita una possibile soluzione

draleo83 ha scritto: Francamente non trovo l’errore.

Infatti se x.dataopen fosse : 12/06/12 e x.time_last fosse : 12/06/12 10.01.43,5

La formula Cast(x.data_open As Text) restituisce regolarmente: 2012-06-12

La formula CAST(x.time_last AS TEXT) restituisce regolarmente :2012-06-12 10:01:43.500

la formula string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) restituisce

2012-06-122012-06-12 10:01:43.500000

RATTASI COMUNQUE DI UN PERFEZIONISMO che ho voluto sperimentare (mi annoia fare sempre le stesse cose ed usare le stesse procedure):

*credo* potrebbe essere un modo più preciso per estrarre l’ultima data dell’accertamento , e per evitare che l’espressione che viene più usata allo scopo

x.data_open >a.data_open

possa mandare in tilt l’intera query (quando lo stesso accertamento è ripetuto nella stessa data può capitare che la query restituisca 0 pazienti)

Admin ha scritto:
Caro Leonardo, non credo che usare Time Last possa rendere più precisa la data più recente: se osservi la tabella seguente:la colonna Time Last non ha niente a che vedere con il momento in cui è stato effettuato l'accertamento. Credo che se proprio si vuole affinare la precisione conviene fare riferimento alla colonna ora che si riferisce al momento della scrittura dell'accertamento.

draleo83 ha scritto:

Admin ha scritto:
Caro Leonardo, non credo che usare Time Last possa rendere più precisa la data più recente: se osservi la tabella seguente:la colonna Time Last non ha niente a che vedere con il momento in cui è stato effettuato l'accertamento. Credo che se proprio si vuole affinare la precisione conviene fare riferimento alla colonna ora che si riferisce al momento della scrittura dell'accertamento.

L'idea di usare la stringa che unisce data_open+time_last mi è venuta per scegliere il più recente, tra 2 accertamenti uguali,inseriti per errore allo stesso paz nella stessa data. Visto che non posso usare data open (perchè riporta la stessa data per entrambi gli accertamenti), ho provato ad usare ANCHE time last (in più rispetto al solo data_open) che ,riportando anche l'ora e i secondi, potrebbe - in teoria-essere adatta. infatti time_last non può essere uguale per entrambi gli accertamenti (sicuramente uno è stato scritto prima e l'altro qualche secondo o minuto dopo). Ho verificato che Sicuramente non porta danni; invece per quanto riguarda l'efficacia del ragionamento va verificata sul campo facendo parecche apposite verifiche e controverifiche (che però non ho ancora trovato il tempo di fare). D'altra parte la sua eventuale utilità riguarderebbe solo casi sporadici. In attesa di approfondire meglio ,mi accontento, per ora, che non porti danni.

Sicuramente se vi fosse una colonna che riportasse l'ora e i secondi (avere solo l'ora in cui è stato precritto l'accertamento non basterebbe), sarebbe meglio; però non mi sembra che ci siano colonne del genere nell'archivio accertamenti (ma non avendo al momendo sottomano la sequenza dei campi di tale archivio non posso giurarci)

Ciao

draleo

Cervino ha scritto:.
Il problema è il seguente :.............Di conseguenza bisogna ricorrere ad una doppia estrazione per aggiungere le colonne mancanti;
un' eventuale semplificazione delle formule potrebbe forse risolvere il problema ?
.................... in caso di campo nullo non aggiunge lo 0 richiesto e devo ricorrere alla formula :

draleo83 ha scritto:
Caro Sergio, andiamo per ordine:

1)formati delle date: non ho capito qual è il formato che serve a te. Quelle che io utilizzo di più sono:

cast(today()as text) restituisce 2012-09-20

cast(today()as char(16)) idem ,in più si può impostare la larghezza della colonna che quì è 16

CONVERT(varchar(16), today(), 103), restituisce gg/mm/ aaaa cioè: 20/09/2012

CONVERT(varchar(10), today(), 103), come sopra ma con larghezza 10

CONVERT(varchar, today(), 105), restituisce gg-mm- aaaa cioè 20-09-2012, con larghezza standard

CONVERT(VARCHAR(16), today(), 105), come sopra, ma la colonna è larga 16

Se queste non fanno al tuo caso, puoi trovarne a dozzine al sito

http://msdn.microsoft.com/it-it/library/ms187928.aspx

sono per MySql della microsoft, ma nell’80% dei casi vanno bene anche per Milleutilità

2) Formato del risultato dell’accertamento.

E’ un vecchio problema, soprattutto con i num decimali es creatinina,BMI,Hbglicata ecc , In cui molti (tra cui io),spesso utilizzano come separatore indistintamente sia il punto che la virgola. E’ anche un problema che personalmente non mi tocca, perché io utilizzo quasi sempre Excel per le mie estrazioni. Estraggo i valori come sono sono e con Excel poi posso trasformarli facilmente in numero, con il formato preferito. Dalla tua risposta mi sembra di aver capito che tu sei costretto ad aggiungere una lunga serie di comandi (quelli da te segnalati in colore blu) per mettere lo 0 quando il risultato è nullo e questa eccessiva lunghezza della procedura manda in tilt tutta la query

Soluzioni ?

Ho modificato la mia query fatta per il collega che estareva l’ultimo BMI dei diabetici e la riporto sotto. Essa Estrae il valore del BMI in formato decimale e se il valore è nullo mette 0.

Naturalmente per altri accertamenti (es creatinina) vanno cambiati i riferimenti, ma la sostanza non cambia. Inoltre ho continuato ad utilizzare l’espressione CAST(a.time_last AS TEXT) perché , mi sembra che la sua efficacia non sia inferiore alle soluzioni tradizionali riportate da Giuseppe; ma è solo un particolare che dipende dai gusti: nulla toglie che tu possa usare altre espressioni equivalenti

Infine alcune considerazioni personali

Credo che il problema da te riscontrato NON sia dovuto al formato delle date o dal num e/o larghezza delle colonne, e/o dal formato dei dati , ma al fatto che l’SQL (soprattutto quello di MW) ha dei limiti:quando la lunghezza e/o complessità delle query superano un certo limite (che non conosco), va in tilt. E’ come la 500: se la si utilizza per una normale attività quotidiana è una buona auto . Si può anche potenziarne le prestazioni, ricorrendo a 1000 geniali artifici -ai miei tempi facevano la 500 abarth - ma rimarrà sempre una 500 e non potrà mai raggiungere le prestazioni di un’auto di fascia superiore .

Per cui se tu non riuscissi a risolvere il problema, fa capire ai colleghi che utilizzeranno la procedura che di fronte ad estrazioni particolarmente complesse (sempre indispensabili ?), la query deve essere spezzata e che occorre un po’ di lavoro anche da parte loro- visto che sono loro i beneficiari-, nel ricongiungere poi 2 o più parti dei risultati

Tra l’altro io non farei neanche tutto questo lavoro per un problema di formati : il formato del dato è un aspetto secondario : è solo il modo in cui questo appare a video; importante non è il formato del dato , ma che il dato sia corretto ( se poi vogliono altri formati, non credo sia un gran problema per loro utilizzare le manine per copiare i 30-40 valori forniti dalla tua query nel formato da loro preferito )

Spero che nella query ci sia qualche spunto utile per risolvere il tuo problema (che tu naturalmente dovrai modificare per adattarlo alle tue esigenze: ma la capacità non ti manca, anzi riesci a fare cose complicatissime con l'SQL di Milleutilità che molti cosidetti professionisti dovrebbero venire a scuola da te)

ciao

Leonardo

----------------------------------------------------------------------------------

SELECT p.cognome,p.nome, p.sesso,DATEDIFF ( yy, p.datanasc,today() ) eta

,CAST(
IF ( SELECT max(a.ac_val) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string( CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)))) IS NULL THEN 0 ELSE
( SELECT max(a.ac_val) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string( CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)))) ENDIF
AS DEC(5,2)) BMI

FROM V_PAZIENTI p
Where EXISTS (SELECT pb.codice FROM cart_pazpbl pb WHERE pb.codice = p.codice AND pb.cp_code like '250%' )

Order By 1,2

Cervino ha scritto:al fine di avere i campi data omogenei e numerose subquery terminano con la clausola :

...And a.data_open Between data_query-1825 And data_query )

compare, al comando Esegui , il messaggio : ... Cannot convert numeric to timestamp

mentre viene acettato il campo : Cast( '2012-12-31' As Date) As data_query,

Cervino ha scritto:comunque la situazione è complessa in quanto i valori decimali vanno convertiti in interi, moltiplicando *10 o *100 : quando il campo è disomogeneo ( interi, decimali con virgola o punto e con uno o due cifre, decimali senza virgola e punto, errori di ortografia, ecc. mentre il formato del BMI è uniforme ad esempio ), scrivere una subquery light diventa ... arduo, almeno per me ...

Cervino ha scritto:comunque la situazione è complessa in quanto i valori decimali vanno convertiti in interi, moltiplicando *10 o *100 : quando il campo è disomogeneo ( interi, decimali con virgola o punto e con uno o due cifre, decimali senza virgola e punto, errori di ortografia, ecc. mentre il formato del BMI è uniforme ad esempio ), scrivere una subquery light diventa ... arduo, almeno per me ...

Cervino ha scritto:
Quindi, semplicemente, esiste una formula per dare all' anno del campo data il formato 4 cifre ( tipo yyyy-mm-dd e simili ), riconosciuto come Data ( Non stringa o Testo ) dall' SQL di MW ?

Grazie per la vostra disponibilità , Vi saluto , Sergio