Many health regions are now incrementally piloting a community EHR, often electing to share specifically composed summaries rather than the original record data held by each enterprise because clinical systems cannot usually share this data directly (Kohane, Greenspun et al. 1996). (Kohane 1996) draws a distinction between distributed EMR systems that are:
Chapter 4: History & Evolution
• local (single institution) in which information is limited to that held by the users institution and
is accessible only from inside that organisational firewall;
• full regional or national EMR systems that retrieve data from multiple legacy systems, using an intermediate translation (abstraction) layer comprising a well-defined information model with standard vocabularies.
(Stead 1997) suggests that a common reference architecture is a necessary enabling stage for the multi-enterprise and regional sharing of patient records. (Stead, Miller et al. 2000) suggest that new generation systems need to use interoperability standards such as HL7, standard terminologies such as LOINC, and knowledge ontologies to give the appearance of data integration from diversely represented and encoded entries. (Glaser 2000) states that information systems need to support clinical team integration as each individual patient receives care across provider sites.
Examples of distributed access to integrated clinical data repositories are beginning to appear in the literature. (Wang, Harkness et al. 1998) describe the design of a web-based read only application for accessing the medical record data held in the Johns Hopkins Hospital and for providing a view into the hospital record to referring physicians. (Stewart and Langer 1998) describe the MIND clinical repository at the University of Washington Academic Medical Centres, which integrates demographics, ICD-9 problems, medication, immunisation, investigation results and transcribed reports to form an electronic medical record (Tarczy-Hornoch, Kwan-Gett et al. 1997). This has been positively evaluated by over 600 clinicians. (van Wingerde, Sun et al. 1998) describe the BiliLIGHT system undergoing trial at the Boston Children's Hospital, which combines a computerised bilirubin management guideline (to prevent neonatal jaundice) with patient record information. The EHR data is obtained from the Beth Israel and Brigham and Women's Hospitals (via W3-EMRS, see Section 4.2.3) and the local hospital record server. (Kittredge, Rabbani et al. 1997) report the introduction of a web-based dial up access to Massachusetts General Hospital admission and discharge information by referring physicians. The Geneva University Hospital now offers GPs access to a secure web interface to a subset of their patients' records (Weber, P and Spahni, S Personal communications).
Many other examples exist as early-release commercial products; most still being validated at selected demonstrator sites. Reports of these evaluations are largely unpublished.
Clinical Data Repositories
Integrated repositories have often been developed to support the need for record interrogation outside the immediate care situation, for example for case reviews and audit, or as a source from which to generate a summary prior to a patient encounter. Examples include:
Chapter 4: History & Evolution
• demographic, financial and cardiac surgery data integrated at the University of Virginia to
provide users with graphs and charts of a diagnosis code against demographic data items or length of stay (Scully, Pates et al. 1997);
• an obstetric data warehouse drawn from Duke University's TMR system, to look for factors contributing to pre-term birth (Prather, Lobach et al. 1997);
• a 46,000 patient record repository in Iowa comprising hospital and community minimum data
sets accumulated over ten years, to investigate the frequency of nursing diagnoses (Delaney, Reed et al. 2000);
• a minimum basic data set repository at the University Hospital of Freiburg with data on over 450,000 patients (going back to 1986), providing a valuable clinical summary (Klar, Zaiss et al. 1995);
• a logical data repository combining microbiology test reporting and a pharmacy system for
antibiotic prescription data at the Henri Mondor Hospital in France, used to detect the early emergence of antibiotic resistance by reviewing short-term trends in organism detection and antibiotic usage (Bouam, Girou et al. 1999);
• radioactive thyroid treatment records captured from paper based worksheets over 35 years at
the Burns Medical Hospital in Honolulu (Nordyke and Kulikowski 1998);
• a data warehouse drawn from the data within the COSTAR system at Massachusetts General
Hospital; (Murphy, Morgan et al. 1999) were able to determine a data set (comprising coded diagnosis, medication and laboratory results) that would satisfy over 90% of user queries and provide a rapid response.
A number of hospitals or health regions are exploring the potential use of data mining techniques to identify new causal relationships or trends in clinical outcome. Present publications suggest that these are at an early stage, have found only weak associations or have duplicated findings already in the medical literature (Abbott, Quirolgico et al. 1998), (Downs and Wallace 2000), (Mani and Cooper 1999), (Nigrin and Kohane 1999), (Brossette, Sprague et al. 1998). The educational value of such analyses for case-based learning has also been proposed (Kircher, Granfeldt et al. 2000).
These repositories are usually integrated by copying data to a centralised database rather than via a federal mechanism. (Mohr 1998) calculates that, once fully established with cumulative data over some years, around 17 Terabytes of storage will be needed for a population of 10 million patients, and a communications infrastructure to enable the addition of 80-200 million new contacts per annum. Solbrig considers it unlikely that these centralised systems will solve the large-scale problems of integrating multiple heterogeneous health information repositories (Solbrig 2000). An approach in which clinical data are maintained within their originating applications and systems but combined at a logical level through federation might offer a more practical and scalable solution.
Chapter 4: History & Evolution