It works, but you have to be patient. It takes a while. Randolph
On 11/8/07, Eddy Rospide <edrs22 at yahoo.com> wrote: > > Hi David, > > The thesis link does not work. > > Thanks, > > Eddy > > *David Ingram <d.ingram at chime.ucl.ac.uk>* wrote: > > The interesting discussion about database persistence layers for EHRs > minds me to point the group to my PhD student Tony Austin's research, which > underpinned the current CHIME clinical cardiology record and decision > support system demonstrators, based on our precursor work to openEHR, in the > EU GEHR and Synapses projects. > > The thesis can be accessed at: > > > http://www.ehr.chime.ucl.ac.uk/download/attachments/71/Austin%2C+Tony+%28PhD+2004%29.pdf?version=1 > > The main quantitative results begin on page 191, although that whole > chapter needs to be read to understand how the tests were set up and > performed. > > Here is the abstract, to give an idea of the scope. It was a huge piece of > experimental work, with live records, and probably could have made two > PhDs; it took a long time! > > The new version of the server, in beta test, is archetype based, but is > not a native implementation of the openEHR Reference Model specifications, > as that is a step too far for us at our demanding clinical application coal > face, at the moment. > > *Abstract of Tony Austin's PhD thesis, April 2004. > > *Records grow and multiply for a patient throughout their life. Healthcare > enterprises are presently > unable to integrate the clinical information continuously accumulating > from patient care or to > communicate it to a point of need. Their medical records are expected to > be legally valid, complete, > accurate, and available in a timely fashion. As a consequence they must be > adequately expressive and > maintained in such a way as to facilitate secure physical retrieval. > This thesis begins by considering the history of structured and electronic > medical records, along with > the histories of distributed systems and databases. It proposes key > infrastructure technologies that > could be used for the development of an electronic healthcare record > server. Two models are then > established, to represent transferable clinical records in general, and to > represent the structure that > those records are required to take. With these there is a means to ratify > healthcare data between > different providers and ensure that received healthcare data of any type > can be meaningfully > processed. > The performance strengths and weaknesses of seven different physical > databases are assessed. These > represent a cross-section of relational, object-oriented and XML > technologies. Another > implementation is created for the purposes of federation. A large-scale > deployment involving > anticoagulant therapy management within a hospital Cardiology Department > provides clinically valid > evaluation data. > An object-oriented model is shown to be highly suited to the task of > representing medical data. > Middleware code converting object model data to any of the database > architecture formats is never > demonstrably the limiting factor in the performance of the overall server. > Consequently relational > databases are equally suitable as persistence engines for medical records. > The new class of XML > databases perform well but incur significant space overhead. > > Hope this may be of interest to those considering these issues, now. > Obviously the world has moved on but the way we tackled the issues may still > have some relevance. > David Ingram, Professor of Health Informatics, > Tel. 020 7288 5965 > CHIME, University College London, > Fax. 020 7288 3322 > Archway Campus, Highgate Hill, London N19 3UA > http://www.chime.ucl.ac.uk _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > 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/20071108/1be70707/attachment.html>
