GSoC 2025: Reporting Framework Discussion

Community GSOC
1

I’m interested in contributing to GSoC with the reporting framework project, but I’m unsure about the best next steps at this stage. I’ve taken a look at the report package in the codebase and thought about writing some tests.
Also, I noticed some redundancy in the sidebar—report types are listed there and again on their respective pages (e.g., Routine, Study). Should I raise an issue for this, or is it an intentional design choice?

@Moses_Mutesasira

2 Likes
2

hello @Huthaifa_Omar , are you meaning this issue here ?. If so, please go ahead and push a PR for it

1 Like
3

@tasksolver Have you received any updates from the mentors regarding reopening this issue?

4

Patient Report Framework - GSoC Project Proposal Update

Hello everyone,

I wanted to share some further refinements to my GSoC project proposal for the patient reporting system. After spending more time with the codebase and writing test cases, I’ve developed this approach that I believe will deliver the functionality we need while maintaining good performance.

User Interaction

I’m thinking of a system where:

  • Users open the patient report page and create queries where each query focuses on a single patient parameter
  • To generate reports, users can combine multiple queries using boolean expressions: ((QueryX AND QueryY) OR QueryZ)
  • Reports will be saved per user profile
  • This approach reduces redundancy and creates a more personalized experience

For example, a user could create queries like “patients with age > 50” or “patients with test result X” and then combine them as needed.

Technical Approach

My initial thought was to create a PatientQueryService with methods like getPatientByX for each parameter, then filter patient lists to match boolean expressions.

However, after further consideration, I believe using the JPA Criteria API would be significantly more efficient. This would allow us to construct a single optimized database query rather than multiple separate queries.

Proposed Architecture

AdhocPatientReport
├── ParameterHandler (interface)
│   ├── applyCriteria(CriteriaBuilder, Root, ...)
│   └── getParameterType()
├── ParameterHandlers
│   ├── AgeParameterHandler
│   ├── GenderParameterHandler
│   ├── DiagnosisParameterHandler
│   └── ... (other implementations)
├── BooleanExpressionParser
└── ReportGenerator

The core of this approach is the ParameterHandler interface:

public interface ParameterHandler<T> {
    void applyCriteria(CriteriaBuilder cb, Root<Patient> root, CriteriaQuery<?> query, Predicate parent, T value);
    String getParameterName();
}

Each parameter type would have its own implementation, making the system easily extensible.

Query Construction Process

  1. Parse the boolean expression into an expression tree
  2. Create a JPA Criteria query
  3. Traverse the expression tree, applying each parameter’s criteria
  4. Create the appropriate Predicates (AND, OR, NOT) through CriteriaBuilder
  5. Execute a single optimized database query
  6. Transform results into the required report format

Benefits

This approach offers several advantages:

  1. Single Database Query: Reduces database load by creating one optimized query
  2. Performance: The database engine can optimize the execution plan holistically
  3. Maintainability: New parameters simply require implementing the ParameterHandler interface
  4. Type Safety: JPA Criteria API provides compile-time checking
  5. Flexibility: Handles complex query combinations without custom SQL for each scenario
  6. Scalability: Adding new parameters requires minimal code changes

I’d appreciate your thoughts on this approach, especially regarding:

  • Are there specific parameter types that should be prioritized?
  • Any performance concerns with the JPA Criteria API in our environment?
  • Are there existing components in the codebase I should leverage?

@mozzymutesa @caseyi - I’m particularly interested in your feedback.

Looking forward to your feedback!

1 Like