Data selection

A method of selecting data, the method comprising, receiving data indicating a first requirement and identifying first records stored in a first database. The first records relate to first data subjects and the identification is based upon the first requirement. The first data subjects cannot be identified from the records of the first database. Second records are identified, the second records being stored in a second database and relating to the first data subjects. The first data subjects can be identified from the identified records of the second database. Each of the second records corresponds to a respective one of the first records, and the identification of the second records is based upon the first requirement.

RELATED APPLICATION

This application claims priority to PCT application PCT/GB2010/001119 filed Jun. 8, 2010, which claims priority to British patent application GB 0910874.7 filed Jun. 23, 2009.

The present invention relates to a method of selecting data. The present invention has particular, but not exclusive, application in allowing the selection of data to which a user has limited access.

Computers are now widely used in a variety of different applications. One particular application relates to the storage of data relating to individuals (sometimes referred to as data subjects) so as to allow that data to be readily available and easily processed. In some cases data relating to large numbers of individuals is stored in a centralized database.

While the storage of data relating to individuals provides benefits both for organizations using that data, the individuals themselves and society at large, there are dangers inherent in centralized storage of large quantities of personal data. For example, many individuals are concerned that their personal data will become known to unauthorized persons who may use the data for illegitimate purposes.

Given the widespread benefits of centralized storage in a variety of fields of activity, considerable effort has been put into securing data so as to ensure that data can only be accessed by authorized users in a controlled manner.

While controlling access to data is important, many currently employed schemes lack flexibility and control access in such a way that users who are not authorized are provided with no access to the stored data. Such an arrangement can cause inefficiencies in that some users who are not authorized to access all of the data, have legitimate cause to access parts of the data, and restrictions preventing all access therefore deprive such users of the benefits of centralized data storage.

Clinical trials may be conducted for a number of purposes, for example to further research into particular treatments for diseases. In many countries, medical researchers are required to conduct clinical trials in order to ascertain and document the safety and efficacy of new medical treatments or devices before those new medical treatments or devices can be authorized for use within that country. Before a clinical trial can begin, a number of steps are often necessary, including a feasibility assessment to determine whether there are enough potential participants to conduct the clinical trial, and subsequently, recruitment of participants.

Individuals determining clinical trial feasibility often do not have access to centralized medical records databases because they are not authorized to access the sensitive personal information contained within such databases. As such, clinical trial feasibility is often assessed on an unstructured basis, by asking clinical staff, such as doctors, for estimates of how many patients with particular characteristics they might expect to see in a given time period. Based on the clinicians' responses, a researcher can estimate, for each clinician willing to involve their patients in a clinical trial, how many eligible patients that clinician is likely to see over the course of the trial. With short deadlines inaccurate estimation of the number of potential eligible participants is common.

Clinical teams may be involved with a number of concurrent clinical trials, each with a different procedure for seeking informed consent during recruitment. The process of recruitment is therefore often laborious and unstructured. There is therefore a need for more efficient clinical trial feasibility assessment and recruitment processes.

It is an object an embodiment of the present invention to obviate or mitigate one or more of the problems outlined above.

According to a first aspect of the present invention, there is provided a method of selecting data. The method comprises receiving data indicating a first requirement; identifying first records stored in a first database, the first records relating to first data subjects and the identification being based upon said first requirement, wherein said first data subjects cannot be identified from the records of the first database; and identifying second records stored in a second database, the second records relating to said first data subjects, wherein said first data subjects can be identified from the identified records of the second database and each of said second records corresponds to a respective one of said first records, and said identification of said second records is based upon said first requirement.

Given that data subjects cannot be identified from records of the first database, data stored within the first database is of relatively low sensitivity, as compared to the data stored in the second database from which the data subjects can be identified. As such, the present inventors have realized that it can be useful to identify records of interest in the first database, and only when records of interest have been identified (based upon the first requirement) to identify records in the second database. Users may have more limited access to the second database, but even if this is the case, the first database can be used to identify records of interest without jeopardizing the security of personal information. For example, by querying the first database a user may be able to determine whether a sufficient number of records satisfy a certain criterion, and if this is the case, the user can then seek to obtain data based upon the identified records stored in the second database. The user may have limited, or no access to the second database, and as such, having queried the first database, the user may request that a third party, authorized to access the records in the second database, perform a desired action based upon the identified records. For example, the user may request that a third party corresponds with individuals to whom the identified record relate.

Identification of the second records may be based upon a second requirement. The second requirement may be based upon a modification of said first requirement, or may alternatively be identical to the first requirement.

The first requirement may take the form of a first a database query and the second records may be identified based upon a second database query. The first database query may be processed to generate said second database query.

The method may further comprise receiving a selection of some of said second records and processing said selected second records. For each respective second record, a first user associated with the respective second record may be identified. The identified first user may be, for example, a user having authorized access to the respective second record. Each respective second record may be provided to the respective identified first user. The or each respective first user may only be provided with second records relating to data subjects associated with the respective first user. As such, access to particular ones of the second records may be restricted to appropriate authorized users.

Said selection of some of said second records may be received from at least one of said first users. Said data indicating a first requirement may be received from a second user. The second user may be provided with access to said selected second records.

Processing said selected second records may be based upon receiving data from the first data subjects associated with said selected second records. For example, the processing may be based upon consent received from the relevant first data subjects. The data received from the first data subjects may therefore comprise data indicating authorisation for a second user to be provided with access to said selected second records.

Receiving a selection of some of said second records may comprise receiving from at least one of said first users a selection of at least some second records provided to the respective first user.

The method may further comprise providing an indication of a number of data subjects based upon the received selection of second records.

Providing a second record to a first user may further comprise providing an indication of said first requirement to the first user.

The method may further comprise providing a first indication of a number of data subjects based upon said identified first records. It may be determined whether said first indication is acceptable. The second records may be identified if but only if it is determined that said first indication is acceptable. The first indication may be provided to said second user, and determining whether said first indication is acceptable may be based upon input received from said second user. If it is determined that said first indication is unacceptable, the method may comprise identifying further first records stored in the first database, the identification being based upon a third requirement.

The method may further comprise processing records in said second database to generate records for insertion into said first database. The processing may comprise selecting at least one record from said second database; identifying first data in said at least one record from which data subjects can be identified; processing said first data to generate second data from which data subjects cannot be identified; storing said second data in said first database.

The first users may be clinicians. The second users may be researchers, and said researches may not be authorised to access records from which data subjects can be identified (i.e. records of the second database). The data subjects may be patients, such that the data stored in the first and second databases is clinical data. Aspects of the invention have application in determining the feasibility of a clinical trial. More specifically, a researcher may make use of the first database to determine how many patients (identified by records of the first database) meet a particular requirement. The researcher may then request that a clinician reviews records of the second database corresponding to the records of interest in the first database, so as to determine whether sufficient patients exist for the clinical trial to be feasible.

Once it has been demonstrated that a particular clinical trial is feasible, eligible participants can be identified and approached in order to obtain informed consent from that participant to enroll that participant in the clinical trial. This process, which requires access to records of the second database can be carried out by a clinician having authorized access to the second database. A potential participant may be approached by that patient's attending clinician during a clinical encounter, or by notification such as a letter.

The methods described herein allow clinical trial feasibility to be assessed while respecting the requirement of ‘Consent for Consent’ that defines the consent required to search an individual's health record to determine whether or not they should be invited to participate in a clinical study. That is, Consent for Consent may be considered to be the consent required to obtain consent from a participant.

It will be appreciated that aspects of the invention can be implemented in any convenient form. For example, the invention may be implemented by appropriate computer programs which may be carried out appropriate carrier media which may be tangible carrier media (e.g. disks) or intangible carrier media (e.g. communications signals). Aspects of the invention may also be implemented using suitable apparatus which may take the form of programmable computers running computer programs arranged to implement the invention.

Referring toFIG. 1, there is shown a general overview of a system in accordance with an embodiment of the present invention. A server1hosts a database2storing subject-identifiable data. That is, the database2stores records relating to individual data subjects from which those data subjects can be identified. The server1provides an interface3to the database2through which one or more authorized users of client computers4access records of the database2. Similarly, a server5hosts a database6storing subject-identifiable data and provides access to the database6through a database interface7. Authorized users can use client computers8to access the records in the database6through the database interface7. Authorization to access the subject-identifiable data stored in either one of the databases2,6is strictly controlled such that personal data associated with the data subjects identifiable from the databases2,6can be accessed only by authorized users using the client computers4,8respectively.

FIG. 1Ashows the client computer4in further detail. It will be appreciated that the client computers8and the servers1,5may take a similar general form. It can be seen that the client computer4comprises a CPU4awhich is configured to read and execute instructions stored in a volatile memory4bwhich takes the form of a random access memory. The volatile memory4bstores instructions for execution by the CPU4aand data used by those instructions.

The client computer4further comprises non-volatile storage in the form of a hard disc drive4c. The client computer4further comprises an I/O interface4dto which are connected peripheral devices used in connection with the computer4. More particularly, a display4eis configured so as to display output from the computer4. Input devices are also connected to the I/O interface4d. Such input devices include a keyboard4fand a mouse4gwhich allow user interaction with the computer4. A network interface4hallows the computer4to be connected to an appropriate computer network so as to receive and transmit data from and to other computing devices, such as the server1. The CPU4a, volatile memory4b, hard disc drive4c, I/O interface4d, and network interface4h, are connected together by a bus4i.

Further users are not authorized to access the subject-identifiable data stored in either of the databases2,6. While, generally speaking, the further users are not authorized to access the subject-identifiable data, it is desirable allow the further users to access particular data in the databases2,6where that data meets certain criteria. It is further desirable that the further users can search for the presence of data meeting those criteria, while maintaining the privacy of the data subjects to which the records of the databases2,6relate. More specifically, the further users should be allowed to access and query data stored in the databases2,6to the extent that it is possible to do so without identifying the data subjects to whom the data relates.

To provide access to the data of the databases2,6while maintaining the requirement of privacy, a server11is configured to host an anonymised database12and to make the database12accessible to the further users via a client computer10which can access the database12through a database interface13. The anonymised database12contains anonymised versions of at least some of the records in the databases2,6. In this way, a user of the client computer10can query the anonymised database12through the database interface13to determine the presence of data meeting particular criteria, without being able to identify individuals to whom that data relates. The server11and client computer10can take a similar form to that illustrated inFIG. 1A.

If it is determined that data in the anonymised database12meets some criteria specified by a user of the client computer10, the user can request that further action is taken, by, for example an authorized user of one of the client computers4,8, where the further action requires access to the subject-identifiable data stored in the databases2,6. Alternatively, the user of the client computer10may request authorization to access the corresponding data from one of the databases2,6. In this way, a user of the client computer10can determine the existence of data meeting specific criteria, without having access to subject-identifiable data to which the user of the client computer10is not authorized, and then request that an authorized user of one of client computers4,8perform a desired action based upon the identified records. For example, the user of the client computer10may wish to correspond with data-subjects to whom the identified records relate, and can request that a user of the client computers4,8(authorized to access the subject-identifiable records of the databases2,6) initiate correspondence on behalf of the user of the client computer10.

In general terms, a line9provides a separation between users of the client computers4,8who are authorized to access data from which individuals can be identified stored in one of the databases2,6, and users of the client computer10who are not so authorized.

An embodiment of the present invention is now described in more detail using an example of clinical trial feasibility determination and clinical trial recruitment.

FIG. 2is a schematic illustration of a system arranged in accordance with an embodiment of the present invention. A server15is configured to host a medical records database16containing a plurality of patient-identifiable medical records. That is, a medical record in the medical records database16contains data that can be used to identify the patient to whom that medical record relates. The medical records database16may be a live medical records database used by clinicians to store and access data or a mirror of a live medical records database.

A second server17is configured to host an anonymised medical records database18containing anonymised versions of at least some of the medical records stored in the medical records database16. The anonymised medical records database18is populated from the medical records database16using a data transfer and anonymisation application19running on the server15. The data transfer and anonymisation application19is adapted to obtain data from the medical records database16, anonymise that data, and insert the anonymised data into the anonymised medical records database18. Details of the operation of the data transfer and anonymisation application19are described below with reference toFIGS. 4 and 5.

The server17is further configured to run a trial protocol design application20, accessible over a network connection21by a clinical trial designer22using a client computer23. While the client computer23is shown inFIG. 2as a PC, it will be appreciated that the client computer23may be any device capable of accessing the trial protocol design application20over the network connection21. The network connection21can take any suitable form, and may be an Internet connection. The trial design application20may be accessed using the Secure Hypertext Transfer Protocol (HTTPS).

The trial protocol design application20is configured to communicate with the anonymised medical records database18, using, for example, appropriate SQL commands. The trial protocol design application20is further adapted to communicate with a trial recruitment application24running on the server15. The trial recruitment application24is accessible through a network25by clinicians26using client computers27. The network25may be any suitable network, and may be the Internet. The trial recruitment application24is adapted to communicate with a query translation module28running on the server15, which is in turn configured to communicate with the medical records database16, using, for example, appropriate SQL commands. Operation of the trial recruitment application24and query translation module28is described in further detail below.

A line29illustrates a notional clinical care boundary. On a clinical care side of the clinical care boundary29, clinicians26, responsible for patient care, have access to patient-identifiable information stored in the medical records database16. On a research side of the clinical care boundary29, the trial designer22does not have access to patient-identifiable information, but merely has access to anonymous data stored in the anonymised medical records database18as is required for the design and refinement of clinical trials. Patient-identifiable data does not cross the clinical care boundary29.

It will be appreciated that, while there is only shown a single server15storing patient-identifiable data in the medical records database16, there may be a plurality of servers each storing patient-identifiable information in respective medical records databases. For example, there may be respective medical records databases in different geographical areas. Where there is more than one server on the clinical care side of the boundary29storing patient-identifiable data, it may be that respective clinicians26can only access particular respective servers, the respective servers storing patient-identifiable data relating to patients for which the respective clinicians are responsible.

Further, the anonymised medical records database18may store anonymised versions of records taken from each of a plurality of medical records databases, thereby allowing a user22to search for data taken from a plurality of medical records databases storing patient-identifiable data without providing the user22with access to the patient-identifiable data stored in the plurality of medical records databases.

The structure of the databases16,18and the process of anonymisation performed by the data transfer and anonymisation application19is now described with reference toFIGS. 3 to 5.

FIG. 3schematically illustrates tables in the medical records database16. Two tables, a Patients table30, a Journal table40, are shown inFIG. 3, although it will be appreciated that the medical records database16may contain other tables in addition to those shown inFIG. 3.

The Patients table30stores patient details, each patient having a single respective record in the Patients table30. Each patient is uniquely identified by a PatientID field31. The Patients table30provides a plurality of fields34to store a patient's personal information, including names, marital status, sex, date of birth, address, telephone numbers, whether or not that patient is deceased, date of death, height, weight, email address, religion, ethnic origin and occupation. The Patients table30has a further plurality of fields35for storing information relating to the general practitioner (GP) responsible for each patient's care. For each record, an UpdatedDate field36stores the date on which the record was last updated.

Each record in the Journal table40stores clinical information about a particular patient in the Patients table30. For each patient in the Patients table30, there may be a plurality of records in the Journal table40. The patient to whom a particular record in the Journal table40relates is identified by a patientID field41, which corresponds with the equivalent patientID field31in the Patients table30. That is, for any record in the Journal table40, the patient to whom that record relates can be determined by matching the patientID field41of that record with the patientID field31of that patient's record in the Patients table30.

The date that each record is created in the Journal table40is recorded in an EntryDate field44. A Rubric field45stores textual information which can be used to record general information regarding the clinical event which prompted the record to be entered. The textual information entered into the Rubric field45may, for example, be a pre-defined description of the clinical event to which the entry in the Journal table40relates. A ReadCode field46stores a code (called a Read Code) used to refer to particular clinical information in a standardised way. Read Codes cover a wide range of topics in categories such as signs and symptoms, treatments and therapies, investigations, occupations, diagnoses and drugs and appliances. A CodeValue field47is used to store the value of the Read Code that is being recorded and a CodeUnits field48stores the units in which the recorded value is measured. For example, if the subject of a particular record in the Journal table40is a patient's blood pressure, the ReadCode field46would indicate an appropriate blood pressure Read Code (for example, a Read Code “XaJ2E” may be used to record a patient's sitting systolic blood pressure) while the CodeValue field47would store that patient's blood pressure measurement and the CodeUnit field48would store the units used to measure the patient's blood pressure, for example, mmHg. If a record in the Journal table40is updated, the time and date of the update may be recorded in an UpdatedDateTime field49. A Source field50can be used to record at which stage in a patient's care the entry in the Journal table is made, for example, the Source field50can be used to record whether the entry is made by during a primary or a secondary care encounter.

FIG. 4schematically illustrates the tables of the anonymised medical records database18. The anonymised medical records database18comprises two tables, a Demographics table60storing data derived from data of the Patients table30and a ClinicalEvents table71storing data derived from data of the Journal table40.

It is now described, with reference toFIGS. 4 and 5how the anonymisation application19anonymises patient-identifiable records from the medical records database16for insertion into the anonymised medical records database18.

Referring to the flow chart ofFIG. 5, at step S1, the data transfer and anonymisation application19selects a subset of records from the Patients table30and the Journal table40in the medical records database16. The subset of records may be selected from the Journal table40based upon a particular condition (identified from the value of the ReadCode field46) recorded in those records. For example, all records relating to patients having Type Two diabetes may be selected. Similarly, records from journal table40may be selected based on some criteria, for example, all records could be selected having an entry in the ReadCode field46of “Hb1Ac” and an entry in the CodeValue field47between 7.5% and 9.0%. Records from the Patients table30, corresponding to the records selected from the Journal table40(identified based upon the PatientID fields31,41) can then be selected. Selection of corresponding records from the Patients table30may involve determining whether a particular record has already been inserted into the anonymised medical records database18. It will be appreciated that the selection of records from the Journal table40and the Patients table30described above is provided by way of example, and that records can be selected from the Journal table40and the Patients table30in any convenient way.

From the subset of records selected from the Patients table30, values stored in the PatientID field31, Sex field34a, DoB field34b, Postcode field34c, Deceased field34d, DeathDate field34e, Height field34f, Weight field34g, EthnicOrigin field34hand UpdatedDate field36are read. Similarly, for the selected records of the Journal table40values stored in the PatientID field41, EntryDate field44, Rubric field45, ReadCode field46, CodeValue field47, CodeUnits field48, UpdatedTime field49, Source field50, DocumentGUID51and SectionGUID field52are read. The remaining fields of the selected records are disregarded.

From the selected data, it is possible that values of the PatientID field31, Postcode field34c, DoB field34band DeathDate field34ecould be used alone or in combination to identify a particular patient, and for each selected record, the values in these fields are transformed before the records are inserted into the anonymised medical records database18, as is now described.

From step S1processing passes to step S2, at which each unique PatientID value in the selected records is mapped to a respective unique randomly generated thirty-two-bit integer. It will be appreciated that, as the generated integer is random, there is nothing to link a particular generated integer with a particular patient's record. A list of all generated random integers is stored at the server15, against which each newly generated random integer is checked to ensure that no two patients are assigned the same randomly generated integer.

Processing then passes to step S3and for each record, the value read from the Postcode field34cis mapped to a corresponding Lower Layer Super Output Area for that postcode (as published by the UK government Office for National Statistics (ONS)). Each Lower Layer Super Output Area (LLSOA) defines a geographical area generally large enough to preclude the identification of any particular individual. It will be appreciated that indicators of geographical location other than postcodes and LLSOA can be used, the requirement being that a second indicator identifies location less precisely than a first indicator.

Processing then passes to step S4and, for each record, the date values in the DOB field34band DeathDate field34eare mapped to a year value and a quartile value. For example, a date of first January nineteen-eighty-two would be mapped to a year value of nineteen-eighty-two and a quartile value of one. Similarly, a date of seventh July two-thousand-nine would be mapped to a year value of two-thousand-nine and a quartile value of three.

Processing then passes to step S5at which data read from the selected records of the Patients table30and Journal table40is inserted into the anonymised medical records database18. In more detail, for each record selected from the Patients table30, a record in the Demographics table60is created. The random integer generated at step S2is stored in the TransformedPatientID field61, the mapped Lower Layer Super Output Area generated at step S3is stored in the LLSOA field62, the mapped date of birth year value is stored in the YearOfBirth field63, the mapped date of birth quartile is stored in the QuartileOfBirth field64, the mapped DeathDate year value is stored in a YearOfDeath field65and the mapped quartile of death is stored in a QuartileOfDeath field66. The Sex, Deceased, UpdatedDate, Height, Weight and EthnicOrigin fields are populated directly from the corresponding fields of each record selected from the Patients table30.

For each record selected from the Journal table40, a record in the Clinical Events table70is created. The random integer generated at step S2is stored in the TransformedPatientId field71, and the EntryDate, Rubric, ReadCode, CodeValue, CodeUnits, Source, DocumentGUID, SectionGUID and UpdatedDateTime fields are populated directly from the corresponding fields of each record selected from the Journal table40.

It will be appreciated that because anonymisation of records to be inserted into the anonymised medical records database18is performed before those records are inserted, no patient-identifiable data crosses the notional clinical care boundary29. That is, only anonymised data is provided to the server17hosting the anonymised medical records database18.

An overview of the system architecture and structure of the databases has been described above. The process of clinical trial feasibility assessment and recruitment according to an embodiment of the present invention is now described with reference toFIG. 2and the flowchart ofFIG. 6.

Referring toFIG. 6, at step S10the clinical trial designer22accesses the trial protocol design application20to input eligibility criteria for a particular clinical trial for which the clinical trial designer wishes to recruit participants.

The trial protocol design application20is configured to receive clinical trial eligibility criteria from a clinical trial designer22and to determine a number of patients who are eligible to participate in the clinical trial by querying the anonymised medical record database4.FIG. 7is a screenshot of an interface provided by the trial protocol design application20that allows the clinical trial designer22to input trial eligibility criteria and submit those trial eligibility criteria for querying against the anonymised medical records database18.

The interface shown in the screenshot ofFIG. 7allows the trial designer22to specify one or more conditions80which can be used to query the anonymised medical records database18. Each respective condition is comprised of an attribute, selected from a respective drop-down menu90, and a criterion that the selected attribute must match. The trial designer22specifies the criterion for each condition80using a respective drop down menu91and a respective text box92. Each respective drop-down menu91allows the trial designer to specify a qualifier such as ‘greater than’, ‘less than’ or ‘is’ (equals), while the text box92allows the trial designer to specify the required attribute value. For example, a patient record will match a condition80ainFIG. 7if that patient record has an Hb1Ac measurement of less than 7.5%.

Add buttons93allow a trial designer22to add further conditions80to the eligibility criteria, while remove buttons94allow a user to remove a particular condition80from the eligibility criteria.

Selection of a radio button95indicates that eligibility for a clinical trial requires a patient to match all of the conditions80, while selection of a radio button96indicates that eligibility for that clinical trial requires only that a patient match at least one of the conditions80. A clear button97clears all of the conditions80. A search button98transmits the eligibility requirements (comprised of the conditions80and the matching criteria as determined by selection of one of the radio buttons95,96) to the trial protocol design application20. Having input the trial eligibility criteria and selected the search button98, processing passes to step S11.

At step S11, the trial protocol design application20uses the eligibility criteria to generate an SQL query to run against the anonymised medical records database18and return a count of the number of patients who meet the submitted eligibility criteria.

Where a particular condition80has an attribute (specified using the dropdown menu90) having a corresponding Read Code, a search is performed on the ClinicalEvents table70to find records that have a value matching that Read Code in the ReadCode field74. For each matching record, it can then be determined if the value in the CodeValue field75meets the criteria of that condition80(specified using the respective dropdown menu91and the respective text box92). If this is the case, the patient to whom that record relates satisfies that condition80.

It may be that a plurality of Read Codes are in use to record data relating to a single attribute, and it may be that for any particular attribute, different, or non-standard, Read Codes are used to record information about that attribute in the Journal table40which are then copied to the ClinicalEvents table70. The use of multiple Read Codes to record the same information could lead to the trial protocol design application20failing to identify all eligible patients if not all of the Read Codes used to record a particular attribute are included in a search for that attribute. To overcome this, a suggested list of Read Codes associated with particular attributes could be presented to the trial designer22in response to selection of a particular attribute in a drop down menu90. The trial designer could then choose which Read Codes to include in the search, and in particular, whether to include non-standard Read Codes. For example, if the trial designer22wishes to search for patients with blood pressure between a certain range, a list of Read Codes which it is known are used to record blood pressure information can be presented to the trial designer22. The trial designer22can then select which of the presented Read Codes he wishes to include in the search.

Where a condition80has an attribute that corresponds to a field in the Demographics table60, a search is performed on the Demographics table60to find records having a value matching the criterion of that condition80in the corresponding field. For example, considering the condition80c, a search would be performed on the Demographics table60to find records where the Sex field82has a value indicating ‘Male’.

Having run the query at step S11it is determined how many patients meet the eligibility criteria by determining how many unique transformed patient IDs are present in the records which match one of the conditions80, and if the radio button96is selected, how many of those unique transformed patient IDs match every condition80. The number of eligible patients is then returned to the trial designer22and processing passes to step S12.

At step S12, the trial designer22decides whether the number of eligible patients returned at step S11is acceptable. If the trial designer decides that the number of patients is not acceptable, processing passes back to step S10and the trial designer22interacts with the trial protocol design application20to test a new set of eligibility criteria by submitting a new set of conditions80. The trial designer22can continue to alter the conditions80until a desired number of eligible patients is returned from the trial protocol design application20. For example, if the trial designer22initially specifies that the age of a patient must be within a certain range and it is indicated that there are too few eligible patients within that age range, the trial designer could modify the conditions80to increase the specified age range.

To aid the trial designer22in altering the eligibility criteria, the trial protocol design application20may return more detailed information, rather than merely returning an integer number of patients matching the eligibility criteria. For example, for each one of the conditions80, the trial protocol design application20may return a count of patients who satisfy that condition. From this, the trial designer is able to see the impact of each condition on the overall total number of eligible patients.

It will be appreciated that while the trial designer can only interrogate the anonymised medical records database18, and is only provided with an integer number of patients, allowing the trial designer22to submit multiple queries creates the possibility of deductive disclosure of patients' personal details. For example, if the trial designer knows that his next-door neighbour is asthmatic, and if a query of the form “+asthma” restricted to the trial designer's Lower Level Super Output Area (LLSOA) returns a single result, then a subsequent query of the form “+asthma+alcoholic” restricted to the same LLSOA will disclose to the trial designer whether or not their next-door neighbour is an alcoholic. It may therefore be desirable for the trial protocol design application20to return a minimum number of patients in response to queries that would otherwise return a number of patients below that minimum number. For example, five may be an appropriate minimum number.

If, at step S12, the trial designer22decides that the number of patients returned at step S11is acceptable, processing passes to step S13at which the SQL query created by the trial protocol design application20based upon the input trial eligibility criteria is sent to the trial recruitment application24running on the server15. Upon receiving the SQL query, the trial recruitment application24sends the SQL query to the query translation module28.

The query translation module28, rewrites the SQL query for execution against the medical records database16to return a set of the clinicians responsible for the patients meeting the conditions specified by the clinical trial designer22. Processing then passes to step S14.

At step S14, the rewritten SQL query is executed on the medical records database16and the results are transmitted to trial recruitment application24. The trial recruitment application24then sends a notification, via email, to each clinician26identified in the results of the rewritten SQL query, that they have patients eligible for a clinical trial.

From step S14, processing passes to step S15at which each identified clinician26accesses the trial recruitment application24to obtain a list of their eligible patients. For example, a link may be provided within the notification email sent to each clinician, wherein selection of the link by a clinician26generates a request for a patient list which is sent to the trial recruitment application24.

When a particular clinician26requests a list of their eligible patients at step S15, processing passes to step S16and the trial recruitment application24re-issues the SQL query to the query translation module28together with the identity of the particular clinician26making a request for their eligible patients. The query translation module28then rewrites the query for execution against the medical records database16to return the identities of all eligible patients under the care of the requesting clinician26. The rewritten query is executed on the medical records database2and the results are transmitted to the trial recruitment application24to be presented to the clinician26.

Processing passes from step S16to step S17at which a clinician26reviews the list of their eligible patients to determine which of the listed patients should be sent invitations for recruitment into the trial. For example, the clinician26may be aware of a patient's personal circumstances that would preclude that patient from taking part in the clinical trial. Details of the trial eligibility criteria in the form of the conditions80may also be transmitted to the clinician26to allow the clinician26to better understand why particular patients under their care have been deemed eligible. It will be appreciated that steps S15, S16, S17are repeated for each clinician26identified as having patients eligible for the clinical trial.

After each clinician26who has patients eligible for the trial has selected their eligible patients, processing passes to step S18and the trial recruitment application24transmits the total number of selected patients to the trial protocol design application20for review by the trial designer22.

At step S19the trial designer22determines whether the total number of patients, selected by the clinicians26responsible for those patients, is acceptable. If the trial designer22decides that the total number of patients is unacceptable, processing passes back to step S10so that the trial designer can alter the eligibility criteria for the trial.

If, on the other hand, at step S19, the trial designer determines that the total number of patients is acceptable, the trial designer22indicates to the trial protocol design application20that trial recruitment can begin. Processing then passes to step S20at which the trial recruitment application24automatically generates personalised invitation letters (or other correspondence, for example, email) for the each clinician26to send to their patients. If a patient agrees to take part in the clinical trial, that patient's details may be provided to the trial designer22, or a different user responsible for conducting the clinical trial.

It is described above how embodiments of the present invention can be used to perform feasibility analysis for use in the design of clinical trials, and for recruitment of patients into the clinical trial while maintaining the requirements of privacy.

It will be appreciated that the present invention has applications extending beyond the use in the design of and recruitment for clinical trials as described above. Indeed, the present invention has application in any area where it is required to maintain privacy of data across a notional boundary. For example, the present application may be used in banking applications where it is it is desirable to provide one set of users, possibly external to the bank, with limited access to customers' financial data.

Further modifications and applications of the present invention will be readily apparent to the appropriately skilled person from the teaching herein, without departing from the scope of the appended claims.