At the heart of CLEF is the compilation of a single coherent “chronicle” for each patient from distributed heterogeneous information that makes up the medical record.  At one level, the Chronicle provides a clear presentation to clinicians and researchers of the course of one patient’s illness.  At another they are data structures which can be easily aligned on “index events” – diagnosis, first treatment, relapse, etc. ‑ and aggregated for statistical analysis to answer questions such as “Of patients with breast cancer with a particular genetic profile, what is the comparison of the time to first recurrence for those treated with Tamoxifen as against those treated with a new proposed drug regimen”.   “How many dropped out of each treatment and why?” “How many required supplementary therapy for the side effects of treatment and why?”

The classic problem for electronic health records is to maintain a faithful, secure, non-repudiatable record of what healthcare workers have heard, seen thought and done. The CLEF HER repositories follow standards designed to achieve these aims – e.g. OpenEHR2, CEN standard 136063, and associated development of “archetypes”.  However, the central issue for CLEF is different – to infer a single coherent view of each patients’ history from the myriad documents and data in the EHR including and to align them with other similar patients in aggregates for querying and research.

CLEF is interested not only in the literal information in the documents but in their clinical significance – not only what was done but also why. It is not enough to know that the report of a bone scan claimed “only osteoporotic changes”. It is necessary to recognise that this indicates that there are “no bony metastases found”. It is not enough to know that the patient was taken off chemotherapy, it is important to know what side effect or concurrent illness intervened. Assembling the chronicle is therefore a knowledge intensive task that relies on inferences. The reliability of these inferences may vary, and it is essential to record not only the inferences but also the evidence on which they were based and their reliability.

Read the full article:   http://www.allhands.org.uk/2004/proceedings/papers/118.pdf

Security and Confidentiality

The key ethico-legal goal of CLEF is to provide mechanisms and policies to ensure that patient privacy and confidentiality are preserved while delivering a repository of medically rich information for the purposes of scientific research. This requires policy/organizational safeguards and a multilevel technical framework.

Royal Marsden Hospital (RMH) is one of the main providers of pseudonymised patient records to the project. An approach has been developed by which real patient records (comprising structured data sets and narrative letters and reports) can be suitably pseudonymised for removal from the ROYAL MARSDEN HOSPITAL and included within the CLEF Electronic Health Record Repository.  The process provides multiple layers for the protection of patient confidentiality and privacy:

†     pseudonymisation – the removal of patient, geographical and organisational identifiers at source.

†     depersonalisation – methods of access via language extraction and generation that conceal or remove potentially identifying information;

†     security – policies and technical measures for the supervision and maintenance of the pseudonymous Electronic Health Record repository as if it contained identified patient records, in conformance with NHS and international standards including privacy enhancing technologies to reduce the risk of re-identification through queries;

†     oversight – specific policies for controlling access to CLEF repository and handling requests to link researchers back to real patients;

†     monitoring – organisational and technical measures to identify potential threats and intrusions.

Read the full article:   http://www.clinical-escience.org/industrial/sep2003/AHM2003-DKalra-CLEF-Security-Confidentiality-Paper.pdf

The need for pseudonymised records

To achieve the aims of the CLEF project, we will need to process potentially sensitive medical information about cancer patients.  Ethically, the source hospital or hospitals cannot release such information to us if it could potentially cause harm to patients.  However, without the information, key parts of the project cannot make progress.    Pseudonymisation of a document is essentially a three-step process:

1.    Identify the sections of the document that contain potentially identifying information

2.    Find and mark the identifying information in the document (noting the type of information, and maybe linking instances which relate to the same individual)

3.    Replace the identifying information with pseudonymous information in a consistent way, i.e. so that instances which related to the same individual in the original text bear the same relation to each other in the pseudonymised version.

This is fairly straightforward, but information is lost in the conversion, as it is no longer apparent from the text whether all the “[HOSPITAL]” tags refer to the same hospital, or different ones.  An improvement on this scheme would be:

Add a tag to the class-based identifiers, to distinguish between different entities of the same class: “[HOSPITAL-1]”, “[HOSPITAL-2]”, etc.

To enable the building of an accurate longitudinal record of care, these cross-references would need to be consistent across all the documents in a single patient’s record.  If it were desirable for the CLEF system to answer queries such as “show me 5-year survival rates for this type of cancer, grouped by the hospital where they were treated,” then the identifiers would need to be consistent across all patients’ records. 

In an ideal world, the whole pseudonymisation process would be carried out by a fully automatic tool.  In practice, steps 1 and 3 could be fully automated, but step 2 will generally require human intervention, if the pseudonymisation is to be 100% complete and accurate.

Question answering and report generation