| 68 | | * I believe that processing the pid_set and eid_set first in the work flow allows the loader to be in control in assigning i2b2 internal identifiers to patients and to events. That is: there is no need for i2b2 internal id's to somehow be manufactured and placed in the PDO '''''beforehand'''''. The source and source identifiers (eg: BRICCS participant id and s-number) can be used as patient identifiers and the loader will take care of assigning internal ids and mapping them to the external source ids. This is a big gain: the process is transactional, it is database independent and there are no problems with concurrency. |
| | 68 | * I believe that processing the pid_set and eid_set first in the work flow allows the loader to be in control in assigning i2b2 __internal__ identifiers to patients and to events. That is: there is no need for i2b2 internal id's to somehow be manufactured and placed in the PDO '''''beforehand'''''. The source and source identifiers (eg: BRICCS participant id and/or s-number) can be used as patient identifiers and the loader will take care of assigning internal ids and mapping them to the external source ids. This is a big gain: the process is transactional, it is database independent and there are no problems with concurrency (multiple processes doing the same thing at the same time). However, although we know what a participant is, we are still somewhat in the dark concerning events: what is an event is in terms of a source system. |
| | 69 | |
| | 70 | * All seven sets or some subset of the seven can be supplied. Even if all seven were supplied, the loader message itself (the web service message that triggers the load process) contains control data which can specify which sets of those present should be processed. The processing will always be done in the above order, even if it has gaps. |
