Onyx to PDO

This is a discussion document and work in progress.

Detailed below are the assumptions underlying importing facts from the BRICCS questionnaire into i2b2. All assumptions are open for discussion.

The Target : i2b2 CRC Cell

The data from an Onyx export will eventually end up in the main i2b2 data warehouse, otherwise known as the CRC cell. The CRC cell has eight tables in which to store data:

1. Observation facts
2. Patient dimension
3. Visit dimension
4. Patient mapping
5. Event mapping
6. Concept dimension
7. Provider dimension
8. Code lookup

The concept dimension can be considered immaterial to importing onyx data into i2b2 on a routine basis. The assumption here is that the concept dimension should be in synch with the ontology cell where the main ontology data is held. Currently, this assumption is partly safeguarded by previous steps in the process which update both the ontology cell and the ontology dimension before we import any participant data.

The code lookup is a lookup table. Basically this is a code-to-description mapping (eg, LCBRU : Leicester Cardiovascular Biomedical Research Unit). Currently no attempt is made to populate the lookup table: it is empty. The code lookup table is considered here to be a minor issue.

The provider dimension holds details of physicians or providers at an institution. Every observation relates (or should relate) to a provider; ie: the observation has been made by a provider. Currently no attempt is made to populate the provider dimension: it is empty.

The patient mapping maps external identifiers (eg: s-number or bpt-number) to an internal i2b2 patient identifier. The favoured way of populating this is via the web service that invokes the CRC loader facility. The alternative is to use a manually supplied number. Either way, the contents of this is relatively uncontroversial.

The event mapping (or visit mapping or encounter mapping) maps external identifiers of a visit to an internal i2b2 event identifier. The latter internal event identifier is similarly uncontroversial to the patient mapping (see above). But the external identifier is a somewhat hazy idea. What constitutes a unique identifier for an event in the BRICCS questionnaire (or for that matter a pathology test)?

That leaves just three tables to consider, and these are the main ones:

The visit dimension holds one row for every visit/encounter/event that a patient is involved in. What is an event with respect to the BRICCS questionnaire? Currently, the process creates just one event for each participant in the questionnaire.

The patient dimension holds one row for every patient (ie: for every participant interviewed in the questionnaire).

The observation facts holds one row for every fact (deemed sensible to include) that has been gleaned about a participant from the questionnaire.