Both the RD connect finder and ERDRI.dor capture the number of cases for a given disease within a registry. Sometimes a registry might house multiple different diseases with different counts for each. Obviously this value could be computed if you can get access to the individual records, but let's suppose for now this isn't always going to be possible and assume there is a use-case for getting at these counts at a registry level.
Summary level metadata about the cases is what I called StudyDesign in the schema diagram. This was loosely based on the description of https://schema.org/MedicalStudy. ERDRI call this section Structure and it covers metadata for things like number of cases and inclusion/exclusion criteria.
I initially suggest we go for something simple in the modelling such as
In this scenario the use of dcat:theme to capture the disease become a bit redundant. We wouldn't want there to be two places in the schema where the disease associated to the registry is described.
Both the RD connect finder and ERDRI.dor capture the number of cases for a given disease within a registry. Sometimes a registry might house multiple different diseases with different counts for each. Obviously this value could be computed if you can get access to the individual records, but let's suppose for now this isn't always going to be possible and assume there is a use-case for getting at these counts at a registry level.
Summary level metadata about the cases is what I called
StudyDesign
in the schema diagram. This was loosely based on the description of https://schema.org/MedicalStudy. ERDRI call this sectionStructure
and it covers metadata for things likenumber of cases
andinclusion/exclusion criteria
.I initially suggest we go for something simple in the modelling such as
In this scenario the use of
dcat:theme
to capture the disease become a bit redundant. We wouldn't want there to be two places in the schema where the disease associated to the registry is described.