Hi Nathan,
   
  It works fine now. I was a bit impatient. As this is a rather large PDF, it 
just took long to show up in the browser.
   
  Thanks,
   
  Eddy

Nathan Lea <n.lea at chime.ucl.ac.uk> wrote:
  Works fine for me (on a Mac using Safari and Firefox)...

What error are you getting, Eddy? We can pick this up outside of the 
mailing list if you want.

With best wishes,

Nathan

Nathan C. Lea
Research Fellow
Electronic Healthcare Records and Information Security
Centre for Health Informatics and Multiprofessional Education
University College London
4th Floor, Holborn Union Building
Highgate Hill
London N19 5LW
www.chime.ucl.ac.uk/~rmhincl
+44(0) 207 288 3798

On 8 Nov 2007, at 18:34, Eddy Rospide wrote:

> Hi David,
>
> The thesis link does not work.
>
> Thanks,
>
> Eddy
>
> David Ingram 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
>

_______________________________________________
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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071108/7ade010b/attachment.html>

Reply via email to