Skip to content

Consider adding a casestudy entry to service_index #296

Description

@johannehouweling

Currently, there is no casestudy entry in service_index.

Strictly speaking, it might not be necessary, as the regulatory question defines the case study. However, this relationship is now being used in search functionality, and other indexes (e.g., methods/data) do include a case study entry.

It might be worth considering adding a casestudy entry explicitly to the data model for consistency and clarity, even if regulatory questions already express this relationship.

The current mapping can already be used to go from Reg. Q -> Case study

Case study Reg Q fields
Kidney reg_q_1a OR reg_q_1b
Parkinson reg_q_2a OR reg_q_2b
Thyroid reg_q_3a OR reg_q_3b

Pros of adding casestudy explicitly to service_index:

  • Simpler filtering/querying: search and UI logic can filter directly on casestudy without translating from reg_q_*.
  • Consistency with other indexes: methods/data already expose this relation, so the model becomes more uniform.
  • Clearer semantics: casestudy is easier to understand than inferring it from regulatory-question fields.
  • Less application-side logic: avoids hardcoded mapping logic in search.
  • Probably stable enough: if regulatory questions are very specific and unlikely to change, duplication risk is lower.

Cons of adding casestudy explicitly:

  • Data duplication: the same relation exists implicitly via regulatory-question fields and explicitly via casestudy.
  • Risk of misalignment: if one side changes and the other is not updated, data can become inconsistent.
  • More maintenance: requires validation or conventions to keep both representations aligned.
  • Potential model ambiguity: it may become unclear which field is the source of truth.
  • Strictly not necessary: if reg_q_* already fully determines the case study, this adds redundancy rather than new information.

Reasonable conclusion
Adding casestudy likely makes sense for usability and consistency, especially if:

  • you already depend on this relation in search, and
  • the regulatory-question mapping is relatively stable over time.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions