Tom, I think it really does depend on the purpose of further use of the data.
clinical : in th e juvenile care record, data on growth and development and vaccinations are stored for 19 year of follow up (in NL). Then archiving is 10 years from that. clinical: if a diabetes diagnosis is based on particular blood glucose tests, and still there is no cure, it will last a lifetime. I have not seen research, but assume that the formal diagnoses and the glucose test this was based on, are stored a lifetime. Statistics: if aggregated from records, depending on architecture decisions, you might want to store the data e.g. on population diseases, over many centuries. Of course the stats themselves are kept in the research db, but how long do we want to trace back the source data for quality assurance and analysis of outliers. So I agree, we need data. The only real research in this area I know about is the algorythms for eg monitors that average the heartrate and similar measures continuously. Although never searched this further, just assumed vendors do their jobs. Vriendelijke groet, William Goossen directeur Results 4 Care -----Original Message----- From: Thomas Beale <[email protected]> To: openehr-technical at openehr.org Sent: Sun, Oct 24, 2010 12:58 pm Subject: Re: Articles on Healthcare, Complexity, Change, Process, IT and the role of openEHR etc I think that the 'pebbles & nuggets' characterisation is probably right, although I don't think anyone knows what the balance is, i.e. at what point it ceases to be worthwhile to trawl back in time. The trouble is you get patients like a 12 yo child with a history of chronic tonsilitis that is only visible by looking at say 10 years of data. Or try the other end of the spectrum - notes by GPs over some years may turn out to be indicative of alzheimers, but only when a diagnostic guideline is applied to say 5 or even 10 years of data. So how far is far enough? I think that what will be needed in the future is a way of filtering out the useless pebbles on the way so to speak. Perhaps when data were archived onto slower media. I wonder if anyone has seen research to indicate how far back data might be useful based on specific morbidities? - thomas beale On 23/10/2010 05:26, Derek Meyer wrote: Tim, I don't claim that all old information is useless. My hypothesis is that clinical care generates vast amounts of information, and very little of this vast amount is useful. (This is an empirical hypothesis, and so could be measured, although I don't know of a study that has. Perhaps a study that a) converts real patient records into facts, and the counts the number of facts, b) requires patients to be seen without a written health record and a treatment plan formulated, c) reviews the treatment plans in the light of the written record, and d) counts facts which result in changes to the treatment plan, e) calculates the ratio of facts that were useful in altering the treatment plan compared with the total number of facts.) My hunch is that there are gold nuggets in historical records, but we have to capture and store too many pebbles to get the nuggets we need. If there was zero cost to capture and storage this wouldn't matter, but unfortunately this is not the case with current technology. This is an economic problem, and the solution is to look for economic benefits at the other side of the time spectrum. If information could be sent to the person who needs it quickly, this time saving could justify the cost of capturing and structuring the information. Once data are structured and captured, it becomes cost effective to do a large number of other things with these data. This is not an argument against openEHR - just another way of using openEHR. Best, Derek. On 22/10/10, Tim Cook <timothywayne.cook at gmail.com> wrote: On Fri, 2010-10-22 at 17:12 +0100, Derek Meyer wrote: > Tony, > > This is very impressive piece of work. Every since I first came > across openEHR I have intuitively felt that it is closer to the > 'solution' than more static attempts at standardization. So why is > progress so slow? I've appplied some lateral thinking to this, and > come up with what many people on this list may (at best) think > contrarian - but at the risk of being flamed.... > > The Case for NPfIT 2.0 www.nationalhealthexecutive.com page 52-53. > > (I'll go get my hard hat now...) All I can say Derek; is that if you think my past medical, mental and social history older than six months is useless information. Much less my familial history of a few generations. I am very happy that you are not my physician. Maybe if you had all of that information in a meaningful semantically connected network. You could practice better preventive healthcare as opposed to band-aid, reactive medicine??? :-) Cheers, Tim -- *************************************************************** Timothy Cook, MSc Project Lead - Multi-Level Healthcare Information Modeling http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link http://timothywayne.cook.googlepages.com/home _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Thomas Beale Chief Technology Officer, Ocean Informatics Chair Architectural Review Board, openEHR Foundation Honorary Research Fellow, University College London Chartered IT Professional Fellow, BCS, British Computer Society Health IT blog _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101025/518365e1/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101025/518365e1/attachment.jpg>
