The CLEF Chronicle: Transforming Patient Records into an E-Science Resource Jeremy Rogers, Colin Puleston, Alan Rector Biohealth Informatics Group, University of Manchester, UK firstname.lastname@example.org email@example.com firstname.lastname@example.org Abstract Electronic patient records are typically optimised for delivering care to a single patient. They omit significant information that the care team can infer whilst including much of only transient value. They are secondarily an indelible legal record, comprised of heterogeneous documents reflecting local institutional processes as much as, or more than, the course of the patient’s illness. By contrast, the CLEF Chronicle is a unified, formal and parsimonious representation of how a patient’s illness and treatments unfold through time. Its primary goal is efficient querying of aggregated patient data for clinical research, but it also supports summarisation of individual patients and resolution of co-references amongst clinical documents. It is implemented as a semantic network compliant with a generic temporal object model whose specifics are derived from external sources of clinical knowledge organised around ontologies. We describe the reconstruction of patient chronicles from clinical records and the subsequent definition and execution of sophisticated clinical queries across populations of chronicles. We also outline how clinical simulations are used to test and refine the chronicle representation. Finally, we discuss a range of engineering and theoretical challenges raised by our work. 1. Introduction The Clinical e-Science Framework (CLEF) project is a United Kingdom eScience project, sponsored by the Medical Research Council. It aims to establish a policy and technical infrastructure through which data arising from routine medical care across multiple sites and institutions may be collected and presented as an aggregated research repository in support of biomedical research . Existing patient records are very rich. A typical example in our research corpus contains a thousand or more numeric data points, a chronology of five or six hundred significant clinical events (clinics attended, drugs dispensed, etc.), plus a couple of hundred narrative documents (letters between doctors, pathology, radiology or body scan results etc.). However, even when in electronic form, most of this data is intended for exclusively human interpretation. Furthermore, much of the critical information is left implicit. To take a common example from the cancer domain, it is rarely stated explicitly why the drug Tamoxifen is being given. Clinicians know that there is little other reason to prescribe it other than to prevent recurrence of breast cancer and, as a general rule, do not bother to record what can be assumed. Similarly, when a drug must be stopped because of its side effects (e.g. anaemia due to chemotherapy), the causal connection between side effect and stopping the drug is rarely mentioned, and even the nature of the side effect itself may have to be inferred from e.g. serial laboratory tests showing low haemoglobin values rather than being explicitly stated as ‘anaemia’. Other partners in the CLEF programme are researching technologies to retrieve useful information from clinical narratives . This paper is a progress report on an orthogonal problem: assuming the full richness of clinical information were available – whether extracted from traditional clinical records post hoc or acquired a priori using entirely different clinical data capture paradigms – how might that information be represented for the maximal benefit of clinical research? Clinicians are particularly interested in certain types of information rarely formalised in current records, e.g. • the precise nature of any imaging investigation (e.g. which anatomical structure was imaged) • the result of any investigation (what was found, what it signifies) • why any investigation was ordered • earlier provisional diagnoses • what symptoms the patient experienced from the disease, or its treatment • when treatment was changed and why • abstractions such as ‘relapse’ or ‘stage’ of disease Our goal is to define a representation supporting increasingly detailed information about patients and allowing us to evaluate its usefulness. We call this novel representation the CLEF Chronicle. 2. Properties of CLEF Chronicle The CLEF Chronicle for an individual patient seeks to represent their clinical story entirely as a network of typed instances and their interrelations. Figure 1 illustrates the general flavour of what we are trying to represent: a patient detects a painful mass in their breast, as a result of which a clinic appointment occurs, where drug treatment for the pain is arranged and also a biopsy of the (same) mass in the (same) breast. The first clinic arranges a follow-up appointment, to review the (same) biopsy, which finds cancer in the (same) mass. This (same) finding is in turn the indication for radiotherapy to the (same) breast. P ain in dication abo ut lo cus B reast D rug plans C linic lo cus p lans C linic plan s lo cus abo ut abo ut lo cus B iopsy fin din g in dication M ass lo cus plan s R adio in dication C ancer F ig u re 1 : In fo rm a l V iew o f P a tien t-H isto ry F ra g m en t (N O T E : T im e-flo w is ro u g h ly left Æ rig h t) In addition to the obvious structural difference between this representation and that of traditional electronic records, any clinical content represented as a CLEF Chronicle should have two central properties: Parsimony – traditional patient records contain multiple discrete mentions of relevant instances in the real world (the tumour, the breast etc). A CLEF Chronicle should have only one occurrence of each. Explicitness – traditional patient records may only imply clinically important information (e.g. the fact of relapse). This must be explicit within a CLEF Chronicle Representation. 3. Functions of CLEF Chronicle Firstly, and most importantly, the CLEF Chronicle is intended to support more detailed, and more expressive, querying of aggregations of patient stories than is currently possible whilst at the same time improving the efficiency of complex queries. More detailed, because the Chronicle is more explicit: we can now ask e.g. how many patients ‘relapsed’ within a set period of treatment. More expressive, because the typing information associated with each Chronicle instance is drawn from a rich clinical ontology, such that queries may be framed in terms of arbitrarily abstract concepts: we can ask how many cancers of the lower limb were recorded, and expect to retrieve those of all parts of the lower limb. This is more efficient, because the traditional organization of patient records tends to require much serial or nested processing of records. Secondly, an individual Chronicle can serve as an important knowledge resource during its own reconstruction from available electronic sources of traditional clinical records. In particular, a Chronicle can help resolve the frequent co-references and repeated references to real-world instances such as characterize traditional records. For example, heuristic and other knowledge linked to an ontology of Chronicle data types can be used to reject any request to instantiate more than one identifier for a [Brain], or any attempt to merge two mentions of [Pregnancy] separated by more than 10 months. Thirdly, the Chronicle is intended to serve as a knowledge resource from which summarising information or abstractions may be inferred. For example, deducing ‘anaemia’ from a run of discrete low blood counts obtained from the traditional record, or ‘remission’ from several years of clinical inactivity and ‘relapse’ when this is followed by a flurry of tests and a new course of chemotherapy. Similarly, where the record does not explicitly say why drug X was given, reasoners browsing a Chronicle may identify condition Y because the drug has no other plausible context of use. Fourthly, the CLEF Chronicle is intended to support automatic summarisation of patient records. Given the sometimes chaotic nature of real patient records, manual case summarisation is recognised as good clinical practice. Manual derivation of such summaries from the content of the record is, however, notoriously time consuming whilst the result of such labours is notoriously out of date whenever it would be most clinically valuable. The fundamental problem is that existing patient records are really “logbooks” (with similar legal significance) of what healthcare staff have heard, seen, thought and done  They often contain contradictory information; each entry reflects the understanding of the problem at the time it was made so that tracing the evolution of problems is non-trivial. The information is recorded in the order in which it was discovered rather than in the order in which it occurred – hence later entries may often include information about earlier events, and a precise diagnosis may not be available until long after the first entries that pertain to it were made. Much of the information is either un-interpreted (for example the serial low haemoglobins already described) or under-interpreted: by convention, radiologists only report what they are confident they have seen on an image. Thus, a typical xray report may state only ‘There is evidence of moderate osteoporosis in the bony spine’ thus leaving it to the requesting physician to infer the more important additional interpretation ‘(but) there are no osteolytic lesions that might suggest to cancer has spread to the bone’. Maintaining summaries of clinical records, therefore, requires them to be transformed from a log whose chronology reflects the time of discovery of the underlying data to one reflecting the order of occurrence of events. Further, the chronology must be recorded at an appropriate level of temporal abstraction such that we may infer our best guest at what happened and how and why the patient was managed. A CLEF Chronicle is intended to be a valuable substrate from which custom summaries of the story may be generated as human readable text. Different summarization strategies (and display vocabularies) can be used for different classes of user, such as for the doctor or the patient. 4. Chronicle Representation The Chronicle Representation comprises a collection of core concepts represented as a Java-based Chronicle Object Model (COM), and more detailed knowledge represented via a set of declarative External Knowledge Sources (EKS). This dual scheme is determined by the differing characteristics of the represented concepts. The architecture also allows for the incorporation of EKS-related inference mechanisms that can assist in the dynamic expansion of the COM (see below). The concepts represented in the COM require associated procedural code of a concept-specific nature. The object-oriented format provides a natural means of achieving this. Though the representation of such concepts might alternatively be divided into declarative and procedural sections, this would result in an inelegant duplication of the model structure. Moreover, we believe the COM will be relatively stable and generic, such that ease-of-update and flexibility are not primary considerations. Conversely, the EKS contain detailed knowledge requiring more regular maintenance, but are less likely to require concept-specific processing. Hence, a declarative format is more appropriate. The precise division between COM and EKS is pragmatic rather than principled. Details are likely to evolve as the Chronicle Representation develops, with concepts crossing the line in both directions. We envisage the EKS as a collection of knowledge sources, ultimately provided by multiple different ontologies, databases and sets of medical archetypes . Similarly, the EKS-related inference mechanisms could be of varying types, including logic-based reasoning systems, rule-base systems, and dedicated procedural mechanisms. The COM is indifferent to how components of the EKS are represented, and how associated inferences are achieved, with both representations and inference mechanisms being accessed via a suitable Java API. Currently, the EKS for the patient chronicle is provided by a single OWL ontology developed specifically to meet our immediate requirements, and the associated inference by a Description Logic  reasoning system (FaCT++ ). This example helps illustrate the two main types of procedures embodied within the COM. These are: P ath olo g y Type L ocu s E K S typ e lo cu s L o cu s P ath olo g y H istory (S P A N ) P ath o lo g y-T yp e E K S h isto ry d escrip tors V a riab le H isto ry (S P A N ) sn ap sh ots targets P ath olo g y S n a p sh o t (S N A P ) sn ap sh o td escrip tors V a riab le V a lu e so u rces C lin ica l P ro ced u re (S N A P o r S P A N ) go a ls C lin ical-G o al E K S C lin ica l G o a l F ig u re 2 : C h ro n icle O b ject M o d el (C O M ) F ra g m en t (S im p lified V ersio n ) The COM has been developed as a standard Javastyle API, primarily for use by the ‘chroniclisation’ mechanisms that we will develop, and the ‘chronicle simulator’ (described below). However, a more generic network-style representation, together with an associated translation mechanism based on the Java introspection facility, is available. This alternative representation provides a means of representing COMbased queries, and is suitable for driving chronicledisplay and query-formulation GUIs. The COM comprises both a generic section and a specific clinical section, with the latter being built upon the former. The generic section includes, most notably, the following: • EKS access facilities; • A temporal model that implements Smith’s SNAP/SPAN distinction . Figure 2 depicts a fragment of the clinical section. It can be seen that the representation of a particular pathology (such as an individual tumour or headache) comprises two main elements: • A single PathologyHistory object, representing the pathology as a SPAN entity through time. • An associated set of PathologySnapshot objects, each representing a SNAP view of the pathology at a specific point in time. The pathology representation also includes, amongst other things, references to EKS concepts representing type (e.g. ‘Tumour’) and location (e.g. ‘Breast’). • Dynamic COM expansion based on EKS knowledge, and EKS-related inference: For example, the EKS that represents pathology-types will provide sets of ‘descriptor’ attributes for each concept (e.g. ‘size’ and ‘shape’ for the ‘Tumour’ concept). These attributes are used to dynamically create sets of both ‘snapshot-descriptor’ and ‘history-descriptor’ fields on the PathologySnapshot and PathologyHistory objects respectively. Furthermore, as the fields in the COM (both static and dynamically-created) are assigned values, the EKS-related inference mechanisms will be consulted, which may result in the provision of additional ‘descriptor’ attributes. Following on from the above example: if the ‘location’ field on the PathologyHistory object is assigned a value of ‘Breast’, then the inference mechanism will infer that an additional ‘descriptor’ attribute called ‘herceptin-2-receptor’ is required. This is a Boolean valued attribute that is only applicable to tumours located in the breast. • Dynamic data abstraction: For example, the value of a ‘history-descriptor’ field is a dynamically updated temporal summary of the values of the corresponding set of ‘snapshot-descriptor’ fields (e.g. if the set of snapshots for ‘Tumour’ records ‘size’ as ‘2’, ‘4’ and ‘7’ mm, the temporal summaries will include ‘max-value = 7’ and ‘strictly-increasing = true’). The COM also involves the expression of various types of data/query creation constraint. 5. The CLEF Simulator Testing or validation of the CLEF Chronicle is problematic because no real patient data contains the details required in machine readable form. Indeed, a major purpose of developing the chronicle is to guide efforts to improve patient records and make them more appropriate for research. Efforts to transcribe manually even small amounts of our experimental corpus of traditional electronic records proved so time consuming as to be impractical. Our solution to this impasse has been to construct a simulator to model breast cancer patients. The processes modelled include the way in which tumour cell colonies grow, metastasise and cause local and systemic effects, the behaviour of the patient both as a biological system and as a sentient healthcare consumer in response to local or systemic symptomatology arising from either the tumour or its treatment, and the actions of the clinician as a provider of investigations of varying sensitivity and treatments of variable effectiveness. The modelling process involves dynamic event-driven interactions through simulated time of all three actors (disease, patient and clinician). The simulator generates simulated clinical stories of similar content and complexity to real life, represented both as chronicles and as note-form text. Whilst the simulator models were engineered to superficially approximate real populations of patients, they do not pretend to possess any predictive properties with respect to, for example, what effect any change in treatment efficacy, or clinical service reconfiguration, might have on real population outcomes. Rather, for our stated purpose of testing the Chronicle as a means to represent individual patient stories, it is sufficient to evaluate whether the complexity and content of individual generated clinical stories approximates that of real clinical stories: whether they have surface truthlikeness, or verisimilitude. Judging the truth-likeness of generated stories is necessarily subjective and imprecise. Formal evaluation would be inherently problematic not least because of the difficulty in obtaining sufficient time from specialist clinicians to serve as the judges. At the present time, therefore, we base our claim that the simulated stories approximate real clinical stories on the following evidence: • The prototype simulator was written by a clinician (JR) and is based on a detailed model of tumour, patient and clinician behaviour and their mutual dynamic interactions. Figure 3 : graphical plot of simulator parameters over course of one simulation • Inspection by JR of several hundred simulations, represented both as short note output (Figure 5) and graphical time-line views of key simulator parameters (Figure 3), did not identify any significantly implausible patients. • Although not designed or required to produce simulated populations of patients with characteristics mimicking those of real populations, 10-year Kaplan-Meier curves (a standard tool for comparing cancer survival) for populations of simulated patients are similar to those for populations of real patients (Figure 4), including those curves representing subanalyses for tumour grade or disease stage at presentation. • Two senior oncology physicians invited to comment on the generated narrative output of simulators Figure 4 : Overall survival curves for real and simulated breast cancer patients suggested only minor changes (e.g. both AST and GGT should appear as liver damage markers). • Queries similar to those forming the central research question in typical registered cancer trials may be constructed and executed against the simulated chronicle repository, as well as more detailed questions such as ‘what effect on long term survival accrues from interrupting a course of chemotherapy in order to go on holiday’. Whilst this provisional evaluation of the simulator suggests that its generated clinical stories are adequate simulacra of reality, its documentation of them in CLEF Chronicle format clearly significantly exceeds that of usual clinical practice both in detail and completeness: it includes many information holders that are not explicitly present in the traditional medical record, in particular the relationships between entities in the story. For example, every test has an explicit causal relation with the phenomenon (usually a problem) that was the reason for requesting the test. Additionally, the simulator records clinically significant entities that are often not only entirely absent from the traditional clinical record, but also would be difficult to automatically infer. These include significant negative investigation findings, the stage of the disease at a given point in time, or exactly when (and on what evidence) a patient changed status from being in remission to being in relapse. Patient notices a problem aged 46 (wk 209) ** Patient presents aged 45.8 (wk 212) ** Ix:Xray chest: normal Ix:Clinical examination showed: a new 4.06cm breast mass Follow-up in 3 weeks with results to plan treatment ** Initial Treatment Consult: week 215 ** ** Surgery ** 4.26 cm lesion was incompletely excised Ix:Histopathology report on excision biopsy Grade 8 invasive ductal adenocarcinoma of breast. Oestrogen receptor negative 21 nodes were positive Six weeks of radiotherapy to axilla should follow surgery Secondaries: commence 6 weeks of radiotherapy. Secondaries: commence 6 weeks of systemic chemotherapy. High grade tumour: for chemotherapy Tumour is hormone insensitive. No hormone antagonist Follow-up in 8 weeks ** Consult to assess response to treatment : week 223 ** Ix:Xray chest: normal Ix:Clinical examination normal No evidence of further tumour. See in 8 weeks Radiotherapy cycle given. 5 remaining Radiotherapy cycle 5 deferred because patient on holiday Radiotherapy cycle given. 4 remaining <<< SNIP >>> ** Consult to assess response to treatment : week 428 ** Ix:Xray chest: abnormal. No new lesions found 2 old lesions found Largest measures 1cm, smallest is 0.7cm High alkaline phosphatatse: for bone scan Ix:Bone Scan: abnormal. No new lesions found 17 old lesions found Largest measures 1.2cm, smallest is 0.7cm Patient confused: for CTScan Brain Ix:CTScan of brain: abnormal. No new lesions found 6 old lesions found Largest measures 1.4cm, smallest is 0.8cm High grade unresponsive tumour. Palliative Care See in 8 weeks ** Died aged 50 from cancer (week 475) ...................................... Grade 8 - 23 local mets, 70 distant metastasis Seen in clinic 19 times and 4 course of chemo prescribed Total tumour mass 1374700 in 200 tumours of which 48 detected. ESR=160 Creatinine=559 41 tumours were destroyed or removed 54 bony mets, total mass 740941 d=5.41cm AlkPhos=4811 Figure 5: Extract of simulator ‘short note’ output Using the simulator output, we may cautiously estimate the richness and complexity that ‘real’ clinical stories – and aggregations of them - might take on if represented as Chronicles. An analysis of a simulated population of 986 patient chronicles revealed: • Individual patient chronicles comprise an average of 385 object instances and 753 semantic relations • The most complicated patient story required 2295 instances and 4636 relationships • The aggregated repository, comprising 986 discrete networks, contained 382,103 instances and 742,595 semantic relations. The prototype simulator and documentation is available for download from: http://www.clinical-escience.org/simulator.html Subsequent releases of the reimplementation may be made available through the same URL in future. We have now developed a more generalised Java re-implementation of the simulator that is capable of creating richer patient records, in a format suitable for populating the Chronicle Object Model. 6. Future Challenges Outstanding issues concerning the Chronicle Representation include: • How to store very large numbers of Chronicle Object Model instances persistently such that queries may be constructed, and efficiently executed, over aggregations of such instances. • How to implement such a query mechanism involving both ontological and temporal reasoning. • How to deal with data arising from the ‘chroniclisation’ of real records will almost certainly be both incomplete and ‘fuzzy’. Other issues concern the presentation of the chronicle to the clinician, including: • How the clinical content of a reconstructed chronicle can be visualised in order to validate its content against the more traditional patient record data from which it has been derived. • How complex queries over sets of patient chronicles can best be formulated by the ordinary clinician. 7. Discussion The idea of representing clinical information as some form of semantic net, particularly focussing on why things were done, is not new: echoes of it can be found in Weed’s work on the problem oriented record . Ceusters and Smith more recently advocated the resolution of coreferences in clinical records to instance unique identifiers (IUIs) . The semantic web initiative offers new possibilities for implementing such an approach, but the lack of any suitable clinical data severely constrains any practical experimentation. The CLEF Simulator provides a useful means to explore some of the computational and representational issues that arise. 8. References 1. Taweel A, Rector, AL, Rogers J, Ingram D, Kalra D, Gaizauskas R, Hepple M, Milan J, Power R, Scott D, Singleton P. (2004) CLEF – Joining up Healthcare with Clinical and Post-Genomic Research. Current Perspectives in Healthcare Computing:203-211 2. Harkema H, Roberts I, Gaisauskas R, Hepple M. (2005) A web service for biomedical term look-up. Comparative and Functional Genomics 6;1-2:86-83 3. Rector A, Nowlan W, Kay S. (1991) Foundations for an Electronic Medical Record. Methods of Information in Medicine;30:179-86. 4. Beale T. (2003) Archetypes and the EHR. Stud Health Technol Inform. 2003;96:238-44 5. Grenon P, Smith B (2004) SNAP and SPAN: Towards Dynamic Spatial Ontology. Spatial Cognition and Computation 4;1:69-104 6. Baader F, Calvanese D, McGuinness D, Nardi D, Patel-Schneider P. (2003) The Description Logic Handbook. Cambridge University Press. ISBN: 0521781760 7. Weed LI (1969) Medical records medical education, and patient care. The problem-oriented record as a basic tool. Cleveland, OH: Case Western Reserve University 8. Ceusters W, Smith B. (2005) Strategies for referent tracking in Electronic Health Records. Journal of Biomedical Informatics (in press). 9. Tsarkov D, Horrocks I. (2006) FaCT++ Description Logic Reasoner: System Description. Proc of Int. Joint Conf. on Automated Reasoning (IJCAR~2006) (in press).