syan tan wrote: > are you suggesting distributed processing then ? With sql, you > can pull the data to whatever supercomputer resources you have at > your elite education centre.
Yes, for aggregate analysis at the supra-practice level, some method for aggregating data is needed. There are many ways of doing this, some far more privacy-preserving than others. My view is that serious attention must be paid to privacy-preservation, and ethics committee oversight or individual patient consent is needed. The latter is infeasible in most circumstances. But ethics committees can provide oversight of *systems* to extract data in a privacy-preserving manner for more central aggregation for research and quality-assurance purposes. They can even give permission for broad classes of ongoing research and quality/safety assurance analysis, so it doesn't need to be hopeless bureaucratic. But proper ethical oversight *is* needed. True distribution processing of statistical measures, in which no data leaves each practice and the "calculation" effectively travels to each site and is done piecemeal until all sites have been visited, is possible but technically complex and still in its infancy (the domain is called "secure multi-party computation"). Central collation of data is still be the best way, but yeah, it can be done ad hoc and in privacy-preserving ways. Supercomputers not needed, though. And a lot of useful analysis can be done within each practice - particularly if "averages" or other pooled summary measures are also available for comparative purposes. Tim C > > On Thu, 2007-04-05 at 09:32 +1000, Tim Churches wrote: >> syan tan wrote: >>>> This analysis now tells us that a sophisticated system for performing >>>> "aggregation" is the primary need of a medical information system - not >>>> "retrieval" as is currently the case. >>>> >>> which is what SQL is supposed to solve, with it's flexible query >>> language and query unifying table views. >> Every tried to fit a time-series regression model with SQL, Syan, or to >> even to calculate an odds ration or relative risk from a contingency >> table derived from individual patient records, using SQL? The latter is >> actually possible, just, but gee, it's really difficult to do and it's >> really not the right tool for the job. >> >> Tim C >> _______________________________________________ >> Gpcg_talk mailing list >> [email protected] >> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >> > > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
