Skip to content

Draft: sphn_hasDataProvider not mandatory

Nicola Stoira requested to merge sphnc-578 into main

We observe two scenarios here (see tables diff):

  • Core concepts without the property sphn:hasDataProvider
  • Core concepts with the property sphn:hasDataProvider defined with minCardinality=0

Up to now we where hardcoding the column sphn_hasDataProvider to all the core concept tables. Nevertheless, there are some concepts where the property does not exists or is not mandatory. How we handle these cases:

  • When generating the JSON schema, we keep track (as we did before for the supporting concepts) of the concepts that define the property sphn:hasDataProvider. We also store if it is a required property or not (by checking the minCardinality).
  • When creating the database schema, we query the table with the data provider references and define the additional default column based on the fact if the property is defined, if it's mandatory, or if it's not defined at all.
  • When extracting the data from the database, we apply the similar logic as the previous point, but we use the results to define the filtering condition on the table. Either sphn_hasDataProvider is matching the one configured, either is NULL, or is not included in the condition.

We assume that the patients extracted from sphn_DataRelease are already filtered on the data provider ID value and therefore the data related to those patient IDs is also related to the same data provider (even if it's not defined in the record because not mandatory).

MR might conflict later on with SPHN only tables. Changes should be implemented there in addition.

Merge request reports

Loading