You’ll have to drop foreign key constraints at least, because for some tables they are referencing reach other. For example, see ‘fpk_concept_domain’ and ‘fpk_domain_concept’ here — since you’ve truncated both tables already, Postgres won’t allow you to load neither CONCEPT (because it would break ‘fpk_concept_domain’) nor DOMAIN (breaks ‘fpk_domain_concept’). The readme file mentions in #5 that foreign key constraints should be applied after loading the data; the “Note” section there is actually misleading because it’s not feasible to load the data with constraints in place.
A side note on vocabulary updates: since you use ATLAS, you might want to keep the vocabularies which were used during the ETL next to the clinical data, and keep them read-only. The reason is that CDMs are tightly coupled with vocabularies they were built with, especially when you use not only the OHDSI-provided concepts but also the custom ones, created specially for your data. But vocabularies constantly change — new concepts are added, some old are deprecated, some made non-standard, some change domains etc. (you can track the details of the changes here), — therefore, it’s usually safer to rerun the ETL with new vocabs if you want to use the latest ones, because you won’t have hard-to-debug situations when e.g. a concept has changed domain but the records in your CDM have not. You can, of course, write a migration script which will update the CDM according to the vocabulary changes, but this is a more error-prone path in general (though might be preferable if your ETL takes ages).
I think this whole thing was described somewhere in the Book of OHDSI, you might want to check it out.
So, instead of truncating the tables, consider the following approach:
- Create a new separate schema for new version of vocabularies and load new data there.
- Rerun the ETL of your clinical data using new vocabularies instead of the ones used before.
- If you don’t need old vocabularies, drop them and use the updated ones going forward.
This process may look too cumbersome, but it saves you a lot of potential headache with the updates.