Following the guides, I have attached a PostgresDB as an OMOP CDM resource. The trouble comes in the assignment below.
o <- ds.omop.helper(connections = conns,
resource = "omop_demo.mimiciv",
symbol = "mimiciv")
#Note that omop_demo.mimiciv might look like myProject.myResource in your case
Error: There are some DataSHIELD errors, list them with datashield.errors()
> datashield.errors()
$SERVER
[1] "Command 'getOMOPCDMTableDS(dsO.3Zh8, table = 'person', dropNA = TRUE)' failed on 'SERVER':
Error while evaluating 'is.null(base::assign('mimiciv', value={dsOMOP::getOMOPCDMTableDS(dsO.3Zh8, table = 'person', dropNA = TRUE)}))' -> Error in postgresqlExecStatement(conn, statement, ...) :
RPosgreSQL error: could not Retrieve the result :
ERROR: relation \"person\" does not exist
LINE 1: SELECT * FROM \"person\" \"q01\" WHERE 0=1\n
Previously we had connected this same Database to Atlas, so I know for a fact that the schema should be OMOP CDM-compliant. What should I do to troubleshoot this problem?
It seems the issue is that the package is not correctly locating the “person” table, and potentially other clinical data tables as well. As you mentioned, if your database was functioning with Atlas, then we can be confident that it is OMOP CDM-compliant. This leaves us with two possibilities:
There may be a configuration issue with the schemas in the resource, which is preventing the package from locating the table within the database.
There could be an additional issue with the package itself, in which case I will investigate further.
Let’s start by ruling out the first possibility. In the latest version of dsOMOP, we added two extra fields for the creation of resources to support cases where clinical data tables and vocabulary tables are located in specific schemas, different from the default one. If possible, could you let me know what schema configuration you applied when creating the resource, and how the tables are distributed across schemas in your database?
2024-10-08 13:19:05.802 UTC [330686] USER@DB ERROR: relation "person" does not exist at character 15
2024-10-08 13:19:05.802 UTC [330686] USER@DB STATEMENT: SELECT * FROM "person" "q01" WHERE 0=1
For the record we have passed the schema name “SCHEMA” both as Schema (optional) and Vocabulary Schema (optional).
We also created a database resource (non-dsOmop) to see if that would change anything
2024-10-08 13:06:51.852 UTC [329915] USER@DB STATEMENT: SELECT * from "SCHEMA"."person"
and sure enought this interpreted the schema correctly.
Thank you for your valuable feedback! I have been able to replicate the issue you are experiencing in our environment and am currently working on a solution. I will keep you updated and let you know as soon as it is resolved.
Thank you for your patience, and apologies for any inconvenience this may have caused.
Best regards,
David
UPDATE: It seems the issue originated from how Opal handles resource URLs. To enable the configuration of parameters such as schemas, we included them within the URL itself, since the resource constructor does not seem to support additional custom parameters. We used the parameters “?schema=” and “&vocabulary_schema=” in the URL, and while these appeared correctly in Opal’s UI, they were not passed to the R session to resolve the resource. As a result, it was unable to locate the schema and the tables within it.
I have updated the way dsOMOP manages resource URLs and pushed the latest changes to the GitHub repository. Installing the latest version of dsOMOP should now resolve the issue. I am currently checking for any similar inconsistencies across environments, but so far, everything seems to be working as expected after these changes. Please let me know if this also solves the problem on your end (you may need to recreate the “OMOP CDM Database” resources after installing the latest version of dsOMOP). Thank you very much!
Just bringing this thread back to your attention, as I have only now realized that if you are following via email notifications, you might have missed my update. I edited the original post rather than creating a new one, which might not trigger a notification. My apologies.
