GB2449705A - Method for Clinical Data Analysis - Google Patents

Abstract

Disclosed is a method and mechanism suitable for clinical and diagnostic data analysis. The clinical data analysis method comprises clinical and diagnostic data capture, association of the captured data with a structured selection means 230, such as a menu, and application of surrogate vectors to the data to provide a binary representation of the data 260. The surrogate vectors are stored in persistent storage and the stored binary representation of the data can then be assessed with respect to clinical protocols.

Description

Method for Clinical Data Analysis The present invention relates to

health care data management. More particularly it relates to the capturing and analysis of clinical and diagnostic data used in a health care setting, where the successful and accurate data capture, analysis and reporting processes are used to optimise treatment outcomes.

Existing clinical data capture and record management systems are dysfunctional. The principle reason for the slow adoption and use of existing systems is that they present a cumbersome and inefficient method of use for the clinician, with most presenting a usage model that is slower than dictating directly to a medical secretary. As patient throughput is a principle driver in health care economics and the personal income of clinical professionals is often proportional to throughput, any system that offers lower patient throughput has an immediate disincentive to adoption.

Existing clinical data capture and analysis systems are comprised of three elements; a user interface, a database, and some form of reporting. The user interface layers are currently cumbersome and inefficient, as mentioned above. A further weakness of existing systems is that data is often poorly structured. A principle reason for this is that many existing systems use free text data entry at the point of capture.

A consequence of the poorly structured data and ad-hoc data entry facilities is that the acquired data has little commercial value and cannot directly be used for quantitative analysis; including the comparison and measurement against recognised clinical protocol measurement criteria.

Conventional medical electronic record systems store data as text in either free-format or in "fields" in relational data-bases. The latter enable multiple "connections", and hence correlations, to be made between fields of text data which is a very powerful tool for analytical purposes.

One problem with these conventional data-bases is that the systems plus their data files are usually "large" as they contain the multiple layers of cross-connecting software. This is particularly true when there are a large number of fields that have to be processed. For example, if there are 50 variables in a data set there are a total of 20,825 possible connections for all permutations and combinations of these variables.

If the data-base contains only a few different files this is not a problem. But, it becomes a very real problem with large numbers of files, say 1,000,000, as the time taken for reading the data files and then subsequent analysis becomes significant even with the very fast modern processors.

These conventional systems store the data in files on hard-disk with the program containing the pointers plus connections to the various items in the data files.

For each analysis operation, data must be accessed from storage before analysis tasks may be performed.

It is an objective of the invention to address one or more of the disadvantages associated with existing systems.

In the invention described here the traditional arrangement of data configuration is replaced with surrogate vector storage or reverse-database architecture. The stored data files contain no data, only the binary fields associated with associated pointers to the data that reside in the program as atomic selction selection structures or menu items.

The current invention includes the embodiment of knowledge capture from clinical practice to a precisely designed clinical data capture system. This system is developed directly out of experience in a clinical environment, specifically to meet the needs of clinical practitioners. The specific characteristics of patient interview and examination procedures are captured in a hierarchical atomic selection (tree) structure and persistent storage system. This is illustrated in the specification with a conversational dialogue between the oncologist and patient, followed by the corresponding hierarchical atomic selection structure or menu interface walk-through, followed by automatic clinical note generation as a worked example. A detailed description of the menu hierarchy and work-flow is shown to capture and enhance clinical practice. It is not known that any other system captures clinical data in such a structured way as to be able to generate natural language clinical note text output with sufficiently robust and accurate content as to not require hand-editing, performing automatic disambiguation. The carefully structured data capture method allows statistically significant analysis on precise clinical attributes, which in other systems are often left undefined or unrecorded or at the very least ambiguous.

The current invention includes a hierarchical atomic selection structure method which may be implemented as a user interface menu. The selection structures are constrained to be a certain size, where each selection structure panel has a maximum of 15 entries and each entry has maximum 21 characters based on human factors research. The functional or operational behaviour of the menu system may be operated by single mouse clicks, with very limited keyboard skills required of the user. This specific aspect is operable to embody the highly tuned specific menu design compared to generic data-base menu front-end systems.

The present invention includes the architecture of the surrogate vector persistent storage alternative to a data-base system, having a number of unique and inventive characteristics from a system architecture viewpoint. Compared to traditional common data-base systems, this is designed in reverse. Most common relational database systems are generic engines designed to be adapted by end-users to a wide variety of tasks. Typical products on the market today are Oracle Database and Microsoft Access. The specific menu structures, table, record and data relationships are loaded at runtime by a database administrator. All application specific configuration and relationship information (schema) are stored in files or the database.

In this way the core database engine has no a priori knowledge of the application set-up. This enables database software vendors to re-use the same generic structures in multiple applications. Unless special precautions are taken, the database files contain full information and may reverse engineered or compromised through security breakdown. Records commonly contain full numeric and textual representations of data requiring compression or encryption to be performed as an explicit step.

However in the present invention, the persistent storage does not hold complete records, only surrogate vectors as digital binary fields, or bit pointers. The clinical data analysis system has the application clinical knowledge structure directly implemented in the application architecture. The menu system is not configured or controlled by data-base schema or tables. The data-base file structure is not a general purpose scheme used in an application specific way; it is an application with domain specific structure. It does not use a general purpose query or update engine.

The use of surrogate vectors arranged in a structured fashion enables key advantages that are unlikely to be found in other systems. First, there is a high level of intrinsic security, as the data files will be meaningless without the clinical data analysis program. The data files only contain binary field bit patterns where individual bits are mapped to menu information positions inside the program, thus have no directly observable meaning out of context. The second advantage is compression. It is unlikely that currently known compression techniques for ASCII text or numerical data arrays could achieve compression levels of one bit per data entry, yet this invention achieves this storage efficiency without explicit compression or decompression operations. The benefits of less memory, less computational steps, lower energy consumption and lower cost computing platforms are clear. A further advantage is in the efficient query and analysis steps, applying analytical assessment processes, where direct Boolean set operations on 4096 bit vectors are performed as an atomic operation, avoiding explicit loops comparing each entry in turn.

The clinical data analysis system includes data capture methods achieved by "clicking" on menu items using the mouse, buttons, touchpad or keys. The menu is an embodiment of atomic selection structure, where the capture of data is constrained to a structured input system. This helps to circumvent any user deficiency in keyboard skills and spelling. Further, the content of the menu items are descriptive words and phrases called primary data units, or PDUs (where PDU concept dates from 1968).

Each instance of the menu is presented to the user in two forms, either multiple choices or a list of individual single choice items. An atomic selection of one menu item switches a given bit in a given 32-bit word from ZERO to ONE, forming an instance of surrogate vector. Hence, a bit set to one represents the address or pointer or surrogate vector sub-field to the item that has been clicked. On data recall, for purposes of data review, analysis, recovery or clinical note production, the clicked items, corresponding to the bits previously set to one, are extracted from the surrogate vectors and "translated" into language by applying suitable grammar rules.

Medical records in general and cancer records in particular present a profound multi-dimensional programming problem. Some of these have been overcome using conventional generic data-base methods, but these are not always adequate for specific applications, including cancer. This is particularly true when large quantities of data of varying complexity need to be extracted and analysed rapidly to assist therapeutic decision making in "real-time". The present invention aims to address some of these problems and restrictions in conventional systems.

According to a first aspect of the present invention there is provided a method for clinical data analysis. This method comprises the steps of; a) capturing clinical and diagnostic data, where the activity is generally performed by a skilled health care professional in a clinical setting, such as during a patient interview; and b) associating captured data with atomic selection structures, where the health care professional selects one or more atomic entries in a selection system such as a menu; and c) associating captured data with a plurality of surrogate vectors, where there is a direct relationship formed between a selection event, perhaps a menu, and a field position within the surrogate vector; and d) applying analytical assessment processes on captured data, in order to extract quantitative values, statistical measures, comparative analysis, to derive clinical information to allow treatment planning and outcome assessment; and e) holding captured data in persistent storage, such that data may be archived, aggregated, distributed, recovered, referenced in a data-base, used to generate offline reports, analysed for different purpose at a later date; in other words data may be saved.

The above steps when taken together form the basis of the clinical data analysis method. The specific combination of methods when operated together allows analytical assessment against clinical protocol measurement criteria, This includes such ICDo-10 disease coding systems and others mentioned in the detailed embodiment.

According to a second aspect of the present invention there is provided a method whereby the capturing of clinical and diagnostic data involves the collection of observations, objective measurement of individual patients, or other data collection activities within a clinical setting. Rather than allowing free-format or open field data entry during the capture process, this method imposes constraints, where those Constraints are manifest by specification of clinical protocols. For instance the location of a breast lesion may be constrained to fall within preset site quadrants of sub areolar region, upper inner quadrant, lower inner quadrant, upper outer quadrant, etc. In this way quantitative constraints are introduced at the point of data capture.

According to a third aspect of the present invention there is provided a method using surrogate vectors, where each vector comprises a digital binary field. Each vector may contain one or more binary fields. Each field may be any width and contain

sub-fields or groups.

According to a fourth aspect of the present invention there is provided a method whereby each surrogate vector comprises a digital binary field of fixed width, such that information coded within the binary field of multiple vectors may be analysed using Boolean set operators over collections of fixed width fields. The association of information within a binary field may be numerical or text entities or single bit sub-fields. Such single bit sub-fields may have associative correspondence to captured data.

According to a fifth aspect of the present invention there is provided a method for holding captured data in persistent storage. Such storage may allow captured data to be archived, aggregated, distributed, recovered, referenced in a data-base, used to generate offline reports, analysed for different purpose at a later date; in other words data may be saved. By virtue of the direct correspondence between surrogate vectors and atomic selection structures, recovery of information is possible by reference only to surrogate vectors. This means that no other data-base, metadata or supplemental information is needed; the surrogate vectors are complete in and of themselves to hold captured data in a persistent state.

According to a sixth aspect of the present invention there is provided a method of analytical assessment producing quantitative results, such as anonymous data extraction, patient nomenclature, disease coding, disease staging, treatment options, treatment responses, side-effect responses, prognostic indexing, and receptor scoring.

Various other analysis functions are included by way of illustration in the embodiment examples in other sections of this document.

According to a seventh aspect of the present invention there is provided a method of analytical assessment, where processing of captured data is used to generate plain text clinical notes in a natural language, either written (presented on a dynamic display screen, on paper, or electronic document, or served as networked webpage) or presented as spoken text, audibly using a text-to-speech (TTS) processor. Such clinical notes are generated using methods of applying grammar rules for the language in question, along with clinical knowledge rules configured specifically for the formation of clinical notes.

According to a eighth aspect of the present invention there is provided a method of disambiguation of captured data. Where uncertainty, ambiguity or conflicting information may be present in the captured data, this is mitigated first by the clinical design inherent in the atomic selection structure or menu system, where care is taken to avoid such possibilities. However, if such ambiguities exist in the captured data, they are further identified and resolved using Boolean set operations over surrogate vectors. Thus processed, the persistent storage of captured data is suitable for quantitative analytical assessment.

According to a ninth aspect of the present invention there is provided a method of analytical assessment where specific information may be obtained through operations of search, look-up, or matching from templates, patterns, and standard assessment criteria. Assessment criteria may be specified arbitrarily by a user, or involve the application of standard clinical protocol criteria.

According to a tenth aspect of the present invention there is provided a method of operating the described methods within the context of various systems, such as an electronic data capture system (EDC), digital record system (DRS), clinical note capture system, digital disease management system, medical diagnostic system, clinical trial information system, health care information management system, NHS Connecting for Health system (National Health Service, UK), or Track Surveys Framework Architecture using Microsoft.Net Framework and MS SQL Server.

According to an eleventh aspect of the present invention there is provided a mechanism for associating captured data with atomic selection structures as a hierarchical tree structure, where at each node of the tree a fixed list of options or choices is applied; whereby any option or choice not activated is identified as non-selection for use in analytical assessment. The hierarchical tree is managed by clinical logic, guiding the user through clinically appropriate data capture options. This may, for example, be embodied in a set of nested menus.

According to a twelfth aspect of the present invention there is provided a mechanism for associating captured data with atomic selection structures in the form of a menu, where each selection structure menu panel has a maximum of 15 entries and each entry has a maximum of 21 characters; and further each entry may be selected buy a single manual action event including mouse click, button press, or key stroke.

The present invention is also embodied in apparatus, mechanisms, products and systems. Possible embodiments include mechanical and electro-mechanical systems.

Further, the present invention may be embodied by a computer program code which directs a computer to perform the methods. Such computer program code may then be configured in the form of a computer program, computer element, and computer product or computer system.

The present invention methods may be illustrated by the following description of an example embodiment: The clinical data analysis system, or digital record system (DRS), is configured to capture Demographic registration data as may be input as text in a similar manner to all existing computer data-base systems. These data are stored in coded form in the first block (0.5K) of the patient record and all of these data are within the public domain. This section is not part of the patent application but it is included for completeness.

The clinical data. These are input by clicking on menu items using the mouse.

Hence, the user does not have to be "keyboard competent". These clinical data are stored in the second and subsequent block(s) of the record. The menus do not contain "sliders" as these are frequently a source of irritation and no menu contains more than items. Additionally, the menu items are restricted to a width of 21 characters. This "21:1 5" configuration was chosen as this was found in a previous application to be the best for minimum user effort with maximum information exchange between computer and user, based on human-computer factors analysis.

The menu system. The menus are of two basic types (with some minor variations-on-a-theme) that contain descriptive terms and phrases called "Primary Data Units" (PDUs). When an item is "clicked" the program changes a given bit in a given word in the data pointer record from zero to one and this then represents the "pointer" to that PDU. These pointers are stored in an array if 128 32-bit words called data_block (4096 bits) that is written to persistent storage (disk) after each section in the data acquisition sequence has been completed. There is a minimum instruction set associated with each menu that cannot be seen by the user. This instruction set gives the program the data required for handling the menu and includes the following.

(a) The number of items in the menu (b) The number of "header" items (c) The number of "hidden" items (d) The number of bits to be assigned in data_block for the menu (e) The type of menu.

Type 1 menus. These are multiple choice menus where any one, or all, items can be clicked. The number of bits assigned in the record must, at a minimum, correspond to the number of items in the menu. For example, if there are 6 menu items then 6 bits would be assigned. In practice more bits than this are generally assigned to accommodate any future expansion of the menu. These menus are always terminated with an << EXIT MENU >> item and, in addition, some contain << HELP >> items for obvious purposes.

Type 2 menus. These are single choice, binomial, menus where only one item can be selected. The number of bits assigned in the record is, at a minimum, equal to the number of bits required to store the numerical value of the number of items in the menu. For example, if there are 7 items in a menu a total of 3 bits would be assigned as this is the number of bits required to store the number 7. In practice, 4 bits are usually assigned as this enables the menu to be expanded to 15 items to accommodate any future expansion.

The clinical data analysis system holds records in two parts; demographic data similar to conventional systems and the surrogate vector binary field structures, also referred to as "data_block", digital pointer system, bit pointers, addresses and reverse data-base architecture. The program uses a multi-dimensional Cartesian-type coordinate system to navigate through the data pointers stored in an array called data_block. The data_block holds information relating to Primary segmentation. This includes a number of discrete functional segments eg. presenting history and investigation requests, where each of these has a unique number, the primary segment number, PSN, alias rcrd_type in the program. The data_block also includes Housekeeping bits. The PSN is always located in the 1st 5 bits at the start of each segment. The next 10 bits identify the word in data_block where the next functional segment is located and the 16th bit identifies the bit in that word where the next record starts, 0 means bit zero and 1 means bit 16. Further, the data_block includes Secondary segmentation. Primary segments may Contain secondary segments. An example is chemotherapy where a number of cycles are delivered. The Secondary housekeeping bits are located in the 2nd 16 bits after the PSN data. The 1st 3 bits give the X-coordinate (see later), the next 5 bits give the TCV, the next 4 bits tell the program how many words to advance to find the next secondary segment, the next bit tells the program to look at bit 0 or 16 in that word and the final 3 bits identify the secondary segment repetition, eg. the cycle number for chemotherapy. In the specific context of Cancer patient treatment planning, the data_block could contain a Therapeutic Component Vector (TCV). This is the treatment strategy chosen by the physician after discussion at the MDI and may include chemotherapy, radiotherapy, surgery and biotherapy. The TCV defines the therapy components and the order in which those components are to be delivered, i.e. the vector. Note the use of the work vector here is clinical, distinct from surrogate vector used elsewhere in this document in the context of numerical data representation. At the program "level", the TCV defines the coordinate structure within the treatment delivery section of the program. Level zero is the presentation and work-up section and the TCV is defined at the end of this. If radiotherapy only is chosen the program next "moves" to level 3 and each of these levels has its own n-dimensional coordinate structure.

The clinical data analysis system also includes through capture, persistent storage, retrieval and analysis functions, specific atomic selection structures and reporting appropriate for 1) Automatic TNMIFIGO staging, 2) Automatic disease coding including ICDo-10, 3) Data-dependent treatment option selection (Including Surgery, chemotherapy, hormones, radiotherapy, biotherapy), 4) Chemotherapy prescribing. Within Chemotherapy, facilities are present that include Protocols within and outside of NICE (National Institute for Health and Clinical Excellence, UK), Physician selected schedules for individualized therapy (not-NICE), Side-effect recording (short-and long-term), Side-effect distinction between chemo and other drugs, Gives drug-drug interaction and sideeffect warnings, Records responses to treatment (objective and subjective). The clinical data analysis system also encodes disease-specific prognostic indices (eg. Nottingham Prognostic Index, NPI).

A representation of the menu driven data capture system, using the atomic selection structure method is shown below, by way of example. Simplified examples of various menus (both types I and 2) taken from the breast cancer data input sequence, are shown below.

BREAST MENUaaa(4)/ 31212', *** PRESENTATION ***, by screening', with symptoms I The array BREAST MENUaaa has 4 elements with the first, 31212, being the instruction set that is NEVER displayed. Starting from the left the 3 is the number of items to be displayed namely, "PRESENTATION", "by screening" and "with symptoms". The first I is the number of hidden items namely the instruction set.

Occasionally, there is a second set of instructions in which case this number would be 2. The first 2 is the number of bits to be assigned in the record. If the item "by screening" is clicked the two bits assigned will have a value if 1. If "with symptoms" is clicked the two bits assigned will have a value of 2. There is no need to assign more than 2 bits as there is no other possible "primary" way in which the patient can present.

The 4th number, the 2nd 1, is the number of "header" items, in this case " PRESENTATION ***" These header items are in UPPER CASE and usually bounded by a number of asterisks. They inform the user as to the purpose of the menu and represent instructions and/or help items to the user. There may be a number of these headers depending on the complexity of the menu. Clicking on any header item produces an error message and the menu is repeated. The last of the 5 numbers, namely 2, tells the program that this is a type 2 menu. If, for example, the user clicks "with symptoms" the 1st 32-bits in the data_block pointer record starting at bit zero becomes: data_block = 0000 0000 0000 0000 0000 0000 0000 0010 The program will now branch to engage BREAST_MENU000 which is the logical sequitur and is shown below.

BREAST_MENU000(9)/ 81811' I*pRESEflNG SYMPTOMS*', bit a lump in the breast' 0 a lump in the axilla', 1 breast skin dimpling, 2 a distorted nipple 13 diffuse induration,4 inflammatory 5 <<EXIT MENU >> I The array BREAST MENU000 has 9 elements, the first of which is 81811.

This means, starting from the left, there are 8 items to be displayed, there is 1 hidden item (the 81811), 8 bits are to be assigned in the record, 1 header item (*PRESENTING SYMPTOMS*) and finally, this is a type 1 menu. Clicking on "a lump in the breast" sets to ONE the first bit (bit zero) of the eight bits assigned. The menu is then returned, as shown below, with this item blanked out which stops it being re-clicked.

I*PRESENTING SYMPTOMS*', bit a lump in the axilla, 1 breast skin dimpling, 2 a distorted nipple 3 diffuse induration 4 inflammatory' 5 <<EXIT MENU >> I The user now has the opportunity to click another item, let's say "breast skin dimpling" which sets to ONE the third bit (bit 2) and the menu is now returned as,- *PRESENTING SYMPTOMS*I, bit a lump in the axilla', 1 I' a distorted nipple,3 diffuse induration,4 inflammatory,5 << EXIT MENU>> I If there are no other items to be recorded the user clicks <<EXIT MENU >>.

These 8 bits now have the "configuration" 00000101 (with 2 bits "spare" as there are only 6 recordable items) and these are inserted into the data_block pointer record to give,-BREAST_MENUaaa BREAST_MENU000 \

III

data_block = 0000 0000 0000 0000 000000 00000101 10

III

bit-->1020 the next record will start here at bit 10 The next 3 menus in this sequence are concerned with examination findings and all are type 2 menus as follows.

BREAST_MENUOO3(5)/ 41312', ** SIDE of LESION, left', right', both sides I This menu assigns 2 bits to the record and clicking on "left" switchesthe next two bits to 01 so data_block is now updated to; data_block = 0000 0000 0000 0000000001 00000101 10 We now need to record the site of the lesion in the breast with the next menu.

BREAST_MENUOO2(10)/ 91412', SITE ** ,value sub areolar region', 1 upper inner quadrant,2 lower inner quadrant,3 upper outer quadrant,4 lower outer quadrant 1,5 axillary tail region,6 filling the breast, 7 Not known /8 This menu requires 4 bits to accommodate the "not known" item and if we click "upper outer quadrant" these next 4 bits are 0100 and data_block is now updated to; data_block = 0000 000000000000010001 00000101 10 The last menu in this particular sequence asks about the duration of the symptom, the lump in the breast, that is established as being in the upper outer quadrant of the left breast from the previous two menus.

BREAST_MENUOO1(8)/ 71312', ** DURATION ** ,value less than 1 month', I less than 3 months,2 about six months,3 more than 6 months,4 about twelve months,5 more than one year 1/ 6 This menu requires 3 bits (3rd number in the hidden item list) and clicking on "about six months" switches the next 3 bits in data_block to 011 ie. a value of 3 to give us the bit sequence of: BREAST_MENUaaa

I

BREAST_MEN U000 \

H

BREAST_MENUOO3 I I I I \IIIII BREAST_MENUO2 \ I I I II \JJJJIJI BREAST_MENUOO1 11111111 \l I 11111 I I data_block = 0000 0000 00000011 010001 00000101 10 The bit sequence in data_block shown immediately above represents the pointers to the following Primary Data Units (PDUs).

PDU MENU HEADER ITEM

"with symptoms" BREAST_MENUaaa PRESENTATION "lump in the breast" BREAST_MENU000 SYMPTOMS "breast skin dimpling" BREAST_MENU000 "left" BREAST MENUOO3 SIDE "upper outer quadrant" BREAST_MENUOO2 SITE "about six months" BREAST_MENUOO1 DURATION The context within which these descriptive PDUs were recorded is known from the "header" items in the menus (shown on the right in the table above) hence, it is possible to convert these data into text by adding the grammar as follows: "This patient presented [with symptoms] that included a [lump in the breast] and [breast skin dimpling] in the [upper outer quadrant] on the [left) side that was present for [about six months]." The sentence above was produced by the natural language clinical note generator or "text generator" involving a grammar rule system in the program and the highlighted [] words and phrases are the PDUs "clicked" on data input and extracted from the bits set to unity in the array data_block. Once the text is prepared, it may be presented to the user in a display screen, hard copy paper, electronic document or transmitted through a network such as a web server to web browser client. Further, the text may be presented audibly using a text-to-speech (TI'S) processor, to aide verification and feedback for the clinical professional.

Surrogate Vector Extraction using Boolean Set Logic The nature of the Surrogate Vector pointer data set is ideally suited to the rapid extraction of specific data using Boolean set logic bit comparison techniques.

This is illustrated in figure 3 which shows two boxes containing various "x" character motifs, where the motif "x-x-x-x-x" is common to both.

The "x-x-x-x-x" motif is common to both boxes hence; the motif in the smaller box 720 is contained within the larger box 710. This condition satisfies the Boolean set logical "AND" inclusion function.

Specific surrogate vector extraction Any combination of specific data can be extracted from the patient's pointer array (see examples in section 2.4) using a template technique in conjunction with the Boolean set logical "AND" function. When the audit/analysis pathway is invoked the program uses a 2nd set of menus that have an extra item *EXCLUDE from AUDIT* added. The system is used in exactly the same way as described in section 1.3.3.3 where the bit sequence is recorded in data_block with io_flag=0 (see section 1.3).

However, there is a subtle difference. If *EXCLUDE from AUDIT* is selected from a menu it switches all the bits in data_block associated with that menu to ZERO. The bit pointer, bit_ptr, is then moved forward as already described in section 1.3.3.4. This is the step by which the user identifies the data that is subsequently to be compared with the patient data. On completion of this identification process the bit sequence is transferred to a variable called template, b_flag is set to ONE and the data files are read from disk into the array data_block.

Boolean comparison Data-pointer match. Let us suppose that the 1st two words of data_block (64 bits) in the patient's pointer record have a bit sequence,-data_block(1,2) = 0100000110000101000001 100010000000100100000001 110100000010100001 and that the corresponding bit sequence in the 1st 2 words of template is,-template(1,2) = 0100000010000100000001 l00000000000000l0000000iOl0000000000i00000 Placing these two bit sequences directly adjacent we can see that wherever there is a bit set in template there is a corresponding bit set in data_block and these correspondences may be noted by vertical alignment in the layout.

data_block(1,2) = 01000001 10000101000001100010000000100100000001110100000010100001 template(1,2) = 0100000010000100000001 100000000000000100000001010000000000100000 Thus, the sequence of set bits in template(1,2) is contained within data_block(1,2) which satisfies the Boolean AND inclusion criterion. In purely practical terms this means that the data we are interested in are contained within data_block. The "pseudo" Fortran-77 statement for the bit comparison of words 1 and 2 in data_block and template is: if (AND(data_block(1,2),template(1,2))-template(1,2).eq.zero) then write(6,*) There is a match' endif -The Boolean function returns the value of template within the AND function because the bits Set in template correspond to those set in data_block. We now subtract template from the Boolean AND, and if the result is ZERO a match has been found.

Data-pointer non-match. Now, let us make a single bit change from 1 to 0 in the patient's data_block bit sequence at bit 42. This is shown below: data_block(1,2) = 01000001 10000101000000100010000000100100000001 110100000010100001 template(1,2) = Boolean Subtract: 0000OOOO0OOO0OOOO0OOO1OOOOO0OOOOoOOOOOOOOOOO0OO0jOO0oO0OODOOO The bit sequence in template(1,2), the pointer data we wish to match, is no longer contained within data_block(1,2) the patient's bit sequence hence, there is no match and the Boolean AND function above returns a non-zero value.

Digital Binary Fixed Width Wide-field comparison technique.

The array template consists of 128 32 bit words (4096 bits) and this occupies a common storage domain (its alias) with an array of 512 character words (8 bits per word) called char_block that also contains 4096 bits. Additionally, the array data_block contains 4096 bits which are all set to zero before reading each patient's pointer set. The whole of the arrays template and char_block can now be evaluated with the Boolean AND function which compares the two sets of 4096 bits in a single operation. This is a very fast procedure that assists in rapid data extraction and analysis, often directly using hardware CPU data registers.

The clinical data analysis system embodiment, or digital record system (DRS), includes specific techniques, methods, menus, clinical logic, data structures and operational support for the following clinical information: Patient Data Demographic Registration Data Surname, Sex, Date of Birth, Address, Referring Doctor, Clinic Medical History, appointments, next of kin, transport, legal info Height, Weight, BP, Blood Type Chemotherapy Regime Selection Pre-agreed Protocols Individual Custom Design Protocols Drug Prescribing Generic Chemotherapy Schedules Automatic Prescribing Surface Area Calculation from Height and Weight The Chemotherapy Prescription Supportive Drugs Hormone Manipulation Radiotherapy Treatment Vector Choice Radiotherapy Action Form Treatment Planning Treatment Monitoring and Audit Recording Treatment Responses Non-parametric measurements Parametric measurements Reporting, Recording, Output Generation Side Effect Recording (Chemotherapy) Short Term Systemic Short Term Evaluation of Drug Side Effect Causation Short Term Local Long Term Side Effect Recording (Radiotherapy) Short Term Systemic Short Term Local Long Term Side Effect Recording (Acute Surgical Complications) Specific Complications General Complications Anonymised Data Extraction Automatic Disease Coding and Staging ICDo-1O Coding TNMIFIGO Staging Disease Staging Prognostic Index and Receptor Scoring Nottingham Prognostic Index (NPI) Receptor Scoring, Oestrogen (ER) Receptors Receptor Scoring, Progesterone (PR) Receptors Receptor Scoring, Her2/Neu Receptor Clinical Note Generation

Language, Grammar, Localisation Specifications

Presentation options, Screen, Print, e-Document, Web, Speech

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings where like numerals refer to like parts and in which: Figure 1 shows a system block diagram of a clinical data analysis system; Figure 2 shows menu driven data capture sub-system of clinical data analysis system; Figure 3 shows two binary fields under comparison for common features; Figure 4 shows Boolean set operation for bit-field comparison schematic; Figure 5 shows flow chart of the generic mapping function directory structure; Figure 6 shows illustration of the arrangement of new directory entries; Figure 7 shows representation of generic directory loading of array; Figure 8 shows table of GNERIC DIR(MF) values by columns; Figure 9 shows flow diagram for extracting anonymised data; and Figure 10 shows a generic system architecture schematic.

DETAILED EMBODIMENTS

Figure 1 shows the System Block Diagram for a clinical data analysis system; where 100 is the core application management controller, responsible for event and data dispatch to other sub-elements within the Electronic Data Capture system. 101 Menus of descriptive terms and phrases, content derived from direct clinical practice. The menus have a specific structure containing both hidden and visible elements. Direct selection interaction with the menus drives the state of the Electronic Data Capture system. 102 The Menu Management System controls the state of the visible menu, Out of a large set of possible menus. The management system determines visibility or individual menu items and communicates changes (bit pattern data) back to the core system. 103 Specific Data Extraction module, responsible for specification retrieval pattern of data corresponding to a specific menu entry. 104 Once menu has specified a query pattern, it is transferred into a template structure for the search operation. 105 Read Data Files. This operation traverses stored data records under investigation. 106 Wide bit-field Boolean analysis operators, highly efficient comparison operators identifying matches between template pattern and actual data.

107 Statistical Analysis Result Reports. Following traversal of relevant data files and Boolean comparison, the results of the analysis are generated as a output report data.

Figure 2 shows a Menu driven data capture system, used by the clinical data analysis system to implement the atomic selection structures. 200 Read Hidden Menu Item, defining metadata for this menu. 210 Extract number of bits (nbits) for menu.

220 Read nbits bits from data_block. 230 Menu system with menu title and list of available choices. 240 Extract Set Bits from data block, previously set or stored. 245 Wide Bit-Field data record, packed bits within record. 250 Corresponding selected menu entries for each "1" bit in Wide Bit-Field. 260 Set data block according to current user selection menu. 270 Advance bit pointer by the number of bits required to store this entry. 280 Text generation, create human readable text formatted for output corresponding to the bit settings in the Wide Bit-Field data record.

Figure 3 shows two boxes, where each box holds a binary field, and where the motif "x-x-x-x-x" is common to both, showing graphical representation of two

digital binary fields 710, 720.

Figure 4 shows Boolean set operation for bit-field comparison schematic where; 300 Set io_flag to zero, display menu; 310 MenuOl shown with Exclude entry at the bottom; 320 MenuO2 shown with Exclude entry at the bottom; 330 Composite wide bit-field record showing bit representations from both menus packed together; 340 Transfer data block to "template" data structure then set data block to zero, set io_flag to 1; 350 Read data file into data block (bit records); 360 Wide bit field Boolean logic comparison between template and dat_block; with 370 data analysis output.

Figure 5 shows flow chart of the generic mapping function directory structure, where; 500 Read the input specification for establishing directory; 510 Increment GNERIC_DIR(1) by ONE to establish a place holder for the new entry; 520 Extract mapping data and generate mapping function, MF from input specification; 530 Check if GNERIC_DIR(MF) is zero or not. If true, proceed to enter data; 540 If false, then set it to true; 550 If first entry is already 1, then proceed to shift functions; 560 Shift up by one place all locations in GNERIC_DATA(n) where n is greater than or equal to GNERIC_DIR(MF); 570 increment by ONE all non- ZERO values of GNERIC_DIR(n) that have values greater than GNERIC_DIR(MF); 580 Load GNERIC_DATA(GNERIC_DJR(MF)) with 2nd part of directory input and pointer to patient in SUB_MASTER; 590 shows Process Exit.

Figure 6 is an illustration of the arrangement of new directory entries that have not previously been "seen" in the directory. This data structure is used for the storage of generic patient record data, such as name, address and other nomenclature.

Figure 6 illustrates the processes involved when there are MF directory entries 900 ("new entry") that have been "seen" previously in the directory. Column 1 shows the directory composition after the 4 entries described in figure 6. The numbers in the top left corner of each panel in figure 7 are the contents of the array GNERIC_DIR(MF).

Figure 7 shows a further generic patient record data structure, where representation of generic directory loading of the array GNERIC_DATA 950 is shown. The numbers in the top left corners of each "cell" are the values in the array GNERIC_DIR(MF) where MF (the mapping function) has four different entries to thedirectory represented by blue, green, yellow and orange. GNERIC_DIR(MF) is the GNERIC_DATA array "start" location for each MF entry. The second column illustrates the insertion of a second "yellow" entry, (MF=632). Referring back to figure we can see that GNERIC_DIR(1) is incremented to 5 then the mapping data are extracted from the input to the directory. The "no" arm is engaged at the first decision fork because the variable GNERIC_DIR(MF) is not zero. The previous entries in GNERIC_DATA equal to or greater than GNREIC_DIR(MF) are then shifted up one location starting with GNER!C_DATA(GNERIC_DIR(1)) which has a value of 5, Thus, GNERIC_DATA(5)=GNERIC_DATA(4), then GNERIQDATA(4)=GNERIC_DATA(3). This "makes room" for the new yellow entry to be inserted at GNERIC DATA(3). However, just before this step is carried out all non-zero locations in GNERIC_DIR with values greater than GNERIC_DIR(MF) are incremented by ONE and the original value in location GNERIC_DATA(3) is now overwritten. The remaining columns (3 to 8) in figure 7 depict the changes when blue, orange, blue, yellow, green and green items respectively are added to the directory in that order and table in figure 8 summarizes the changes to GNERIC_DIR.

Figure 8 shows GNERIC DIR(MF) values by columns, where 800 is Table showing correspondence of MF value by columns. The table is used as part of the access and index method to manage generic patient data.

Figure 9 shows flow diagram for extracting sequential records from the array BIG_BUF, the anonymised data. The flow diagram items are 600 Create template to control data extraction process; 610 Read arionymised data into input buffer, set up pointer; 620 Extract bits corresponding to field in input buffer; 630 Check if template fits the extracted bit pattern from input buffer; 640 Record match identified; 650 Increment word pointer to next logical record area of buffer; 660 Check if buffer word pointer is greater than zero, if not exit.

Figure 10 shows an overview of generic system architecture. A generic overview of the system architecture is shown in figure 10. However, it must be stressed that there are a number of possible variations on this theme and the particular system installed will depend on specific user requirements. 400 Clinical Practitioner User Interface (Html, Tcl/Tk, Java), plurality of users using system to capture new information in a clinical environment. Menu content is typically delivered through a web browser program. 410 Web server, EDC Facility as Managed Service. This provides access to the EDC through Internet web services, responding on demand from browser requests elsewhere on a network. 420 Administrator User-Interface, Anonymised Patient Data Only. Derived and modified version of menus, allowing 3rd parties, including administrators, regulated access to stored data in anonymised form.

430 EDC Back-End Service, Rules and Menu Logic. The EDC control system and programs accessed as services connected via the web server 410. 440 Wide Bit-Field Records (menu pointers only). Data records only contain packed bit pointers, not full descriptive fields. 450 Secondary data storage facility (menu pointers only). Data can be moved or backed up on secondary storage devices.

Insofar as embodiments of the invention described above are implementable, at least in part, using an instruction configurable programmable processing device such as a Digital Signal Processor, FPGA, microprocessor, other processing devices, data processing apparatus or computer system, it will be appreciated that program instructions for configuring a programmable device, apparatus or system to implement the foregoing described methods is envisaged as an aspect of the present invention.

The program instructions (such as, for example, computer program instnictions) may be embodied as source code and undergo compilation for implementation on a processing device, apparatus or system, or may be embodied as object code, for example. The skilled person would readily understand that the term computer in its most general sense encompasses programmable devices such as referred to above, and data processing apparatus and computer systems.

Suitably, the program instructions are stored on a carrier medium in machine or device readable form, for example in solid-state memory, magnetic memory such as disc or tape, optically or magneto-optically readable memory, such as compact disk read-only or read-write memory (CD-ROM, CD-RW), digital versatile disk (DVD) etc., and the processing device utilises the program instructions or a part thereof to configure it for operation. The program instructions may be supplied from a remote source embodied in a communications medium such as an electronic signal, radio frequency carrier wave or optical carrier wave. Such carrier media are also envisaged as aspects of the present invention.

Although the invention has been described in relation to the preceding example embodiments, it will be understood by those skilled in the art that the invention is not limited thereto, and that many variations are possible falling within the scope of the invention. For example, methods for performing operations in accordance with any one or combination of the embodiments and aspects described herein are intended to fall within the scope of the invention.

The scope of the present disclosure includes any novel feature or combination of features disclosed therein either explicitly or implicitly or any generalisation thereof irrespective of whether or not it relates to the claimed invention or mitigates any or all of the problems addressed by the present invention. The applicant hereby gives notice that new claims may be formulated to such features during the prosecution of this application or of any such further application derived therefrom. In particular, with reference to the appended claims, any number of features from any one or more claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the claims.

For the avoidance of doubt the term "comprising", as used herein throughout the description and claims is not to be construed solely as meaning "consisting only of'.

References International Classification of Diseases for Oncology (1990) 2nd edition Eds Percy, van Holten and Muir. Published by World Health Organization, Geneva.

ISBN 92-4-1544147-7 Leake, R., Barnes, D., Pinder, S., Ellis, I., Anderson, L., Anderson, T., Adamson, R., Rhodes, T., Miller, K., and Walker, R. (2000) "Immunohistochemical detection of steroid receptors in breast cancer: a working protocol" J. Clin. Path. : 634-635 Schechter, A.L., Stern, D.F., Vaidynanthan, L., Decker, S.J., Drebin, J.A., Green, M.I.

and Weinberg, R.A. (1984) "The neu oncogene: An erb-B-related gene encoding a 185,000-Mr tumour antigen" Nature 312: 513-5 17 Stotter, A. (1999) "A prognostic table to guide practitioners advising patients on adjuvant systemic therapy in early breast cancer" Eu. J. Surg. Oncol. : 341-3 TNM classification of malignant tumours (1997) 5th edition, Eds Stobin and Wittekind. Published by Wiley-Liss, New York, Chichester, Weinheim, Brisbane, Singapore, Toronto. ISBN 0-471-18486-1 Watson, J.V. and Williams, M.V. (1999) "A new audit method for assessing quality of radiation delivery" Brit. J. Cancer 80:2 60 (abstract) Zigmond, A.S. and Snaith, R.P. (1983) "The hospital anxiety and depression scale" Acta Psychiact. Scand. Jun:(6): 361-70

Claims (28)

1. A method for clinical data analysis comprising steps: a) capturing clinical and diagnostic data; and b) associating captured data with atomic selection structures; and c) associating captured data with a plurality of surrogate vectors; and d) applying analytical assessment processes on captured data; and e) holding captured data in persistent storage; where said atomic selection structures and said association of captured data with surrogate vectors are suitable for said analytical assessment against clinical protocol measurement criteria.

2. A method according to Claim 1, wherein step a) includes one or more of collection of observations, objective measurement of individual patients; and wherein step b) includes constraining captured data association at the point of collection according to clinical protocols.

3. A method according to any preceding claim, wherein step c) includes using surrogate vectors where each vector comprises a digital binary field.

4. A method of Claim 3, wherein step c) further includes using digital binary field of fixed width suitable for Boolean set operations over collections of surrogate vectors; and where binary field may include single bit associative correspondence with respect to captured data.

5. A method according to any preceding claim, wherein according to step e), captured data is held in persistent storage; and persistent storage is suitable to Store surrogate vectors; and recovery of captured data is possible by reference to only surrogate vectors.

6. A method according to any preceding claim, wherein step d) includes analytical assessment producing quantitative results, where said results include one or more of; anonymous data extraction, patient nomenclature, disease coding, disease staging, treatment options, treatment responses, side-effect responses, prognostic indexing, or receptor scoring.

7. A method according to Claim 6, wherein said analytical assessment generates plain text clinical notes in natural written or spoken language; and includes methods of applying grammar rules suitable for the formation of said clinical notes.

8. A method according to any preceding claim, wherein analytical assessment is performed by Boolean set operations over surrogate vectors including operations suitably configured to perform disambiguation over captured data.

9. A method according to any preceding claim, wherein said analytical assessment includes one or more methods of searching, look-up, or matching from templates.

10. A method according to any preceding claim, wherein clinical data analysis is operated within one or more of; electronic data capture system, digital record system, clinical note capture system, digital disease management system, medical diagnostic system, clinical trial information system, health care information management system, or NHS Connecting for Health system.

11. A clinical data analysis mechanism comprising components; a) a mechanism for capturing clinical and diagnostic data; and b) a mechanism for associating captured data with atomic selection structures; and c) a mechanism for associating captured data with a plurality of surrogate vectors; and d) a mechanism for applying analytical assessment processes on captured data; and e) a mechanism for holding captured data in persistent storage; where said atomic selection structures and said association of captured data with surrogate vectors are suitable for said analytical assessment against clinical protocol measurement criteria.

12. An mechanism according to Claim 11, wherein component a) includes one or more of mechanisms for collection of observations, objective measurement of individual patients; and wherein component b) includes a mechanism for constraining captured data association at the point of collection according to clinical protocols.

13. A mechanism according to Claim 11 through Claim 12, wherein component c) includes a mechanism using surrogate vectors where each vector comprises a digital

binary field.

14. A mechanism according to Claim 11 through 13, wherein component c) further includes a digital binary field of fixed width suitable for Boolean set operations over collections of surrogate vectors; and where binary field may include single bit associative correspondence with respect to captured data.

15. A mechanism according to Claim 11 through 14, wherein according to component e), captured data is held in persistent storage; and persistent storage is suitable to store surrogate vectors; and recovery of captured data is possible by reference to only surrogate vectors.

16. A mechanism according to Claim 11 through 15, wherein component d) includes analytical assessment operable to produce quantitative results, where said results include one or more of; anonymous data extraction, patient nomenclature, disease coding, disease staging, treatment options, treatment responses, side-effect responses, prognostic indexing, or receptor scoring.

17. A mechanism according to Claim 16, wherein said analytical assessment is operable to generate plain text clinical notes in natural written or spoken language; and is further operable to apply grammar rules suitable for the formation of said clinical notes.

18. A mechanism according to Claim 11 through Claim 17, wherein analytical assessment is operable to perform Boolean set operations over surrogate vectors suitably configured to perform disambiguation over captured data.

19. A mechanism according to Claim 11 through Claim 18, wherein said analytical assessment mechanism is operable to perform one or more of searching, look-up, or matching from templates.

20. A mechanism according to Claim 11 through Claim 19, wherein the clinical data analysis mechanism is operable within one or more of; electronic data capture system, digital record system, clinical note capture system, digital disease management system, medical diagnostic system, clinical trial information system, health care information management system, or NHS Connecting for Health system.

21. A mechanism according to Claim 11 through Claim 20, wherein the mechanism for associating captured data with atomic selection structures has a hierarchical tree structure, where at each node of the tree a fixed list of options or choices is applied; whereby any option or choice not activated is identified as non- selection for use in analytical assessment. -

22. A mechanism according to Claim 11 through Claim 21, wherein the mechanism for associating captured data with atomic selection structures is embodied in the form of a menu, where each selection structure menu has a maximum of 15 entries and each entry has a maximum of 21 characters; and further each entry may be selected buy a single manual action event including mouse click, button press, or key stroke.

23. A computer program product comprising a computer usable medium having computer readable code embodied in said computer usable medium, said computer readable program code comprising computer readable program code for causing at least one computer to provide the clinical data analysis mechanism of Claims 11 to 22.

24. A computer program product comprising a computer usable medium having computer readable code embodied in said computer usable medium, said computer readable program code comprising computer readable program code for causing at least one computer to be operable to perform methods of Claims 1 to 10.

25. A computer program element substantially as hereinbefore described.

26. A computer program product substantially as hereinbefore described.

27. A computer system substantially as hereinbefore described, and with reference to the accompanying drawings.

28. A clinical data analysis mechanism substantially as hereinbefore described, and with reference to the accompanying drawings.