... | @@ -62,6 +62,11 @@ Due to the fact that the resource types are read in random order, it may happen |
... | @@ -62,6 +62,11 @@ Due to the fact that the resource types are read in random order, it may happen |
|
<details>
|
|
<details>
|
|
<summary> Show data flow of Encounter, Procedure, Observation, MedicationAdministration and Condition resources </summary>
|
|
<summary> Show data flow of Encounter, Procedure, Observation, MedicationAdministration and Condition resources </summary>
|
|
|
|
|
|
|
|
---
|
|
|
|
When a Encounter/Procedure/Observation/MedicationAdministration/Condition resource is read in, the job first checks whether the referenced Patient resource and Encounter resource already exists in OMOP CDM. This is done in the FHIR_ID_TO_OMOP_ID_MAP table using the logical_id and/or the identifier. If the referenced Patient resource and Encounter resource already exists in OMOP CDM, the existing person_id and visit_occurrence_id will be used (= omop_id from FHIR_ID_TO_OMOP_ID_MAP).
|
|
|
|
|
|
|
|
Due to the fact that the resource types are read in random order, it may happen that the referenced Patient resource and Encounter resource is not yet available in OMOP CDM. In this case, a dummy for the Patient resource and a dummy for the Encounter resource is created and written to OMOP CDM. If the "real" Patient resource and Encounter resource is to be written to OMOP CDM during incremental loading, only an update of the dummies takes place.
|
|
|
|
|
|

|
|

|
|
|
|
|
|
</details>
|
|
</details>
|
... | | ... | |