7.4. CRATE’s Python regex NLP¶
CRATE provides several simple numerical results processors. Each comes with a corresponding validator.
The processor looks for full results in text, like “his CRP is 10 mg/L today” or “CRP | (H) | 17”, and will extract the number, units, and so forth. It does so by matching a keyword (such as “CRP”, “C-reactive protein”, “C reactive protein”, etc.) plus other attributes such as an optional tense indicator (“is”, “was”), an optional relationship (“equals”, “<”, etc.), a value, and units. Units may be optional, and some units may be recognized and specifically disallowed. For example, “MMSE 25/30” or “MMSE 25 out of 30” may be allowed, where variants on “out of 30” are the units, and “MMSE 25” can be treated as if it were implicitly out of 30, but “MMSE 25/29” disallowed.
In addition to the standard NLP output columns, the processor produces these output columns:
Column | SQL type | Description |
---|---|---|
variable_name | VARCHAR(64) | Variable name (e.g. ‘CRP’) |
_content | TEXT | Matching text contents |
_start | INT | Start position (of matching string within whole text) |
_end | INT | End position (of matching string within whole text) |
variable_text | TEXT | Text that matched the variable name (e.g. ‘CRP’, ‘C-reactive protein’). |
relation_text | VARCHAR(50) | Text that matched the mathematical relationship between variable and value (e.g. ‘=’, ‘equals’, ‘less than’) |
relation | VARCHAR(2) | Standardized mathematical relationship between variable and value (e.g. ‘=’, ‘<=’) |
value_text | VARCHAR(50) | Matched numerical value, as text |
units | VARCHAR(50) | Matched units, as text |
value_mg_l (*) | FLOAT | Numerical value in preferred units, if known |
tense_text | VARCHAR(50) | Tense text, if known (e.g. ‘is’, ‘was’) |
tense | VARCHAR(7) | Calculated tense, if known (e.g. ‘past’, ‘present’) |
… plus any fields you elected to copy.
The name of the column marked (*) will vary from processor to processor (e.g. value_mg_l for the CRP processor; value_kg for the Weight processor; value_m for the Height processor). The columns may vary from processor to processor; for example, the blood pressure (BP) processor produces two numbers per entry (a systolic and a diastolic BP).
The validator simply looks for the corresponding keyword. It doesn’t record much information except for a reference to the source row.
In addition to the standard NLP output columns, a typical validator produces these output columns:
Column | SQL type | Description |
---|---|---|
variable_name | VARCHAR(64) | Variable name (e.g. ‘CRP’) |
_content | TEXT | Matching text contents |
_start | INT | Start position (of matching string within whole text) |
_end | INT | End position (of matching string within whole text) |
… plus any fields you elected to copy.
To look at things the validator recognized but the processor didn’t like, you can do something like the following. This example was created for a database with string source PKs (yuk) on Microsoft SQL Server (which sometimes requires a slightly convoluted way of specifying table names).
SELECT text -- field with the free text in
FROM crissql_v3.dbo.Progress_Notes -- source table
WHERE document_id IN ( -- primary key
SELECT _srcpkstr FROM crissql_workspace.[CRIS-CPFT\RCardinal].validate_crp
) AND document_id NOT IN (
SELECT _srcpkstr FROM crissql_workspace.[CRIS-CPFT\RCardinal].crp
)
This should produce text where CRP is mentioned but no value given, such as “FBC, TSH, vitamin B12, CRP and eGFR are all within normal range”; “blood sample taken (CRP/U&Es and FBC)”; “monitoring CK and CRP”; “CRP was back up yesterday”.
For a table with integer PKs you would use _srcpkval
instead of
_srcpkstr
.
Specimen timing on a slow system (2016-11-15): 5,954 seconds (1h40) for a full run of 2,717,779 text notes (one per database row, from a table with a string PK) through 40 NLP tasks (20 main, 20 validator) on a virtual computer mimicking 2×2.7GHz CPUs running Windows Server 2003, with all databases under SQL Server hosted elsewhere over a network. That works out at 18.2 kHz for processor-notes or 456 Hz for notes. (The corresponding do-nothing incremental update, with the –skipdelete option, took 4,756 s. That’s not much faster, and was limited primarily by queries for a record indicating that each datum had previously been processed. The advantage of incremental updates can be considerably more than this if the NLP step is slow, as with GATE and other more complex systems, but regular expressions are pretty quick.) Fast computers with local networks and SSD storage should perform considerably better, and tables with integer PKs are also processed faster because their work can be more efficiently and evenly assigned to parallel processes.