v2.4.0

CHANGE-LOG.md

@@ -1,5 +1,131 @@
 # OpenStudyBuilder (OSB) Commits changelog
 
+## V 2.4
+
+New Features and Enhancements
+============
+
+### Fixes and Enhancements
+
+- Corrections and improvements to Library -> Concepts -> Compounds and Studies -> Define Study -> Study Interventions.
+- Simplified model for Activity Group and Subgroup. The link between subgroup and group has been removed. Activities are now free to choose any combination of group and subgroup. This change was made to make it easier to maintain the Activity library.
+- Define Study, Study Structure, Design Matrix now support definition of SDTM transition rule.
+- Adding two new flag attributes on relationship from Activity Instance Class to Activity Item Class for indicating if this is to be a default linkage or an additional optional selection. 
+- Improvements on field labels in activity instance wizard stepper.
+- User guide added in documentation portal for neodash CRF Library Version report.
+- Support for USDM version 4.0. Note only for a partial scope, additional scope coverage will be gradually added in subsequent releases.
+- In 'Define Study/Study Structure/Study Visits page' the Epoch column now stay visible when 'edit mode' is selected and the column selections doesn't reset when page is changed. 
+- Removes duplicated query parameter to /concepts/activities/activities endpoints that splits one Activity object if it contains more than 1 activity grouping into separate instances. The same can be obtained by using already existing group_by_groupings query parameter.
+- Activity requests (placeholders) can now be exchanged for multiple activities.
+- The wizard stepper for creating activity instances now includes enhanced form restriction messages, more user-friendly notifications, and improved stability across the different phases of the form.
+- Implement openapi.json changes to use unique titles for classes to enable class generators using titles as keys.
+
+### New Feature
+
+- It is now possible to onboard interventional device studies.
+- The users will be able to set up studies with overlapping Main and Extension parts now as well as split Main and Extension SoAs in protocol.
+- Study complexity score number added to the Detailed SoA page.
+- Consumer API improved to support extract of masked audit trail data for process data mining.
+- Study Data Specification, Study Activity Instances now support linkage to study data suppliers including definition of origin type and origin source.
+- 'EU PAS number' added to registry identifiers, which will allow to onboard relevant (in-house) NIS and DAS studies.
+- Initial pilot implementation of linking CRF elements to the Activity Instances and Activity Items, as the biomedical concepts in OSB. This is to support creation of initial CRF library content with Activity Concepts linkage. The implementation will continue with usability improvements in coming releases.
+- The Study Activity Instances table now includes an edit mode, enabling batch add/modify of Important flag, Baseline visits and Data Supplier details (Name, Origin Type and Source) directly in the table.
+- Added feature flags to control visibility of Study Data Suppliers page and create button in the UI.
+- Added feature flag configuration entries (disabled in production, enabled in E2E test environment).
+- Improved navigation within the collapsed visit functionality: 
+  - Guidance on why some visits cannot be collapsed
+  - That collapsed visits groups cannot be edited 
+  - Handling of footnotes in collapsed visit groups and 
+  - Possibility to collapse non-consecutive visits in a list view (relevant for large SoAs)
+
+### Performance Improvements
+
+Faster editing of Study Design Matrix on 'Study Structure > Design Matrix' page
+
+### End-to-End Automated test enhancements
+
+- Various code improvements to ensure easier maintenance and overall tests stability.
+- Library > Concepts > Activities > Activity Instances: Tests refactorization to support changes for NumericFindings Activity Instance Class.
+- Library > Concepts > Activities > Activity Instances: Defined and Implemented test for checking requested activities visibility in the Wizard Stepper.
+- Library > Concepts > Activities > Activity Instances: Defined and Implemented test for checking visibility of selected activity in the Wizard Stepper.
+- Library > Concepts > Activities: Adjusted tests to removal of group-subgroup linkage.
+- Studies > Define Study > Study Structure > Design Matrix: Defined and Implemented tests for checking transition rules.
+- Studies > Define Study > Study Structure > Study Visits: Defined and Implemented tests for multiple visits on same day.
+- Studies > Define Study > Study Properties > Study Type: Updated tests for Study Development Stage Classification
+- Studies > Define Study > Study Activities: Defined and Implemented tests for exchaning study activity and activity placeholder.
+- Studies > Define Study > Study Activities > Protocol SoA: Defined and Implemented tests for splitting the view.
+- Studies > Define Study > Study Activities > Detailed SoA: Updated tests for collapsing visits.
+- Studies > Define Study > Study Activities > Detailed SoA: Defined and Implemented tests for Complexity Score.
+- Studies > Define Study > Study Activities > Detailed SoA: Defined and Implemented tests for verification of placeholders visibility.
+- Studies > Define Study > Data Specifications > Study Activity Instances: Defined and Implemented tests for verification of placeholders visibility.
+- Studies > Define Study > Data Specifications > Study Activity Instances: Defined and Implemented tests for edition mode.
+- Studies > Define Study > Data Specifications > Study Activity Instances: Defined and Implemented tests for assignment of Data Suppliers.
+
+Solved Bugs
+============
+
+### CDISC
+
+ **Import** 
+
+- Update CDISC import script to use author_id for user identification
+
+### Library
+
+ **Concepts -> Activities -> Activities** 
+
+- Missing loading indication when switching between statuses
+- Search field value cleared when switching between status filter
+
+ **Concepts -> Activities -> Activity Instance Classes -> Overview Page** 
+
+- Search refresh issue
+
+ **Concepts -> Activities -> Activity Overview Page** 
+
+- Duplicated items in Activity groupings table
+
+ **Data Collection Standards -> CRF Builder -> Items** 
+
+- Edit Item - Alias - Rows per page - All
+- Removed term are still selectable at the Item level
+
+ **Overview Pages -> Study Structures** 
+
+- Filters values are not sorted
+- Poor performance on filtering
+
+### Studies
+
+ **Define Study -> Data Specification**
+
+ - Sorting Activity Instance Column Returns an Error
+
+ **Define Study -> Study Activities -> Schedule of Activities** 
+
+- Visit grouping in locked protocol SoA
+
+ **Define Study -> Study Properties -> Study Attributes** 
+
+- Error thrown when trying to edit attributes of study subpart
+
+ **Define Study -> Study Structure -> Design Matrix** 
+
+- Incorrect Pagination
+
+ **Define Study > Study Structure > Study Epochs** 
+
+- Study Epoch API is not robust against changes in CDISC codelists
+
+ **Manage Study > Study Core Attributes** 
+
+- Not possible to edit study to update study number or project
+
+ **Study List -> Study List** 
+
+- Blocked save button, when trying to add a study with already existing number
+
+
 ## V 2.3
 
 New Features and Enhancements

README.md

@@ -11,6 +11,13 @@ OpenStudyBuilder is the open source version of the internal StudyBuilder solutio
 
 For further information on the OpenStudyBuilder solution, please refer to the [OpenStudyBuilder homepage](https://openstudybuilder.com).
 
+## Related Repositories
+
+The following repositories are related to OpenStudyBuilder
+
+- [OpenStudyBuilder-Word-Add-In](https://github.com/NovoNordisk-OpenSource/openstudybuilder-word-addin)
+- [OpenStudyBuilder-accelerators](https://github.com/NovoNordisk-OpenSource/openstudybuilder-accelerators)
+
 
 # Introduction
 

clinical-mdr-api/.env.example

@@ -1,5 +1,5 @@
 # Application Settings
-APP_NAME="Clinical MDR API"
+APP_NAME="OpenStudyBuilder API"
 UVICORN_ROOT_PATH="/"
 APP_DEBUG=false
 COLOR_LOGS=true
@@ -65,7 +65,7 @@ SCHEMATHESIS_HOOKS="clinical_mdr_api.hooks.schemathesis_hooks"
 
 # Third-party Integrations
 MS_GRAPH_INTEGRATION_ENABLED=true
-MS_GRAPH_GROUPS_QUERY="\$filter=startsWith(displayName, 'StudyBuilder')"
+MS_GRAPH_GROUPS_QUERY="\$filter=startsWith(displayName, 'OpenStudyBuilder')"
 
 # gzip API responses (Content-Encoding: gzip)
 GZIP_RESPONSE_MIN_SIZE=1000

clinical-mdr-api/.github/agents/code-generator-consumer-api.agent.md

@@ -0,0 +1,130 @@
+---
+name: Consumer API Code Generator
+description: Code generation agent for the Consumer API (reads/writes under consumer_api/, follows existing patterns, and creates tests).
+---
+
+# Code Generation Agent
+
+You are an expert software engineer specialized in reading existing codebases and generating new code that follows established patterns and conventions.
+
+## Capabilities
+
+- Analyze existing code structure, patterns, and conventions
+- Generate new code that matches the existing codebase style
+- Understand multiple programming languages and frameworks
+- Follow SOLID principles and best practices
+- Create tests alongside implementation code
+
+## Instructions
+
+When asked to generate code:
+
+1. **Analyze the context**: Read relevant existing files to understand:
+   - Code structure and architecture
+   - Naming conventions
+   - Error handling patterns
+   - Type annotations and documentation style
+   - Testing approaches
+
+2. **Follow existing patterns**: Match the style and patterns found in:
+   - Similar classes/functions in the codebase
+   - Related modules and components
+   - Test files for similar features
+
+3. **Generate complete code**: Provide:
+   - Full implementation with proper imports
+   - Type hints and documentation
+   - Error handling
+   - Corresponding test files if applicable
+
+4. **Explain key decisions**: Briefly note:
+   - Why certain patterns were chosen
+   - Any assumptions made
+   - Suggestions for improvements if applicable
+
+## Project Structure Awareness
+
+When generating code, ensure that:
+- New files are placed in appropriate directories
+- Module imports reflect the project structure    
+
+### File structure
+- `consumer_api` - this is the main codebase for the Consumer API. You READ from and WRITE code to this directory.
+   - `consumer_api/v1` - this is where the API routes are defined. You READ from and WRITE code to this directory.
+   - `consumer_api/tests` - this is the test codebase for the Consumer API. You READ from and WRITE code to this directory.
+   - `consumer_api/requirements` - this is where the user requirements specifications, functional specifications and traceability between requirements and test are defined. You READ from and WRITE code to this directory.
+
+
+## Response Format
+
+When generating code, structure your response as:
+
+1. Brief summary of what's being generated
+2. Code blocks with file paths
+3. Short explanation of key implementation choices
+4. Any follow-up actions needed (migrations, config updates, etc.)
+
+## Examples
+
+### Example 1: Add API Endpoint
+
+**User prompt**: "Add endpoint to export audit trail as CSV"
+
+**Your response should**:
+- Analyze existing endpoints structure
+- Match routing patterns
+- Follow authentication/authorization patterns
+- Reuse existing service methods where possible
+- Include proper OpenAPI documentation
+- Generate corresponding tests
+
+## Tools Usage
+
+- Use `semantic_search` to find similar implementations
+- Use `grep_search` to locate patterns and conventions
+- Use `read_file` to understand full context of related files
+- Use `list_code_usages` to see how existing functions are used
+
+## Best Practices
+
+- Always validate inputs
+- Use proper type hints
+- Add docstrings for public methods
+- Handle edge cases and errors
+- Follow the principle of least surprise
+- Prefer composition over inheritance
+- Keep functions focused and testable
+
+## Language-Specific Guidelines
+
+### Python
+- Follow PEP 8 style guide
+- Use type hints (PEP 484)
+- Prefer list comprehensions for simple transformations
+- Use dataclasses or Pydantic models for structured data
+- Handle exceptions appropriately
+
+### Cypher (Neo4j)
+- Use parameterized queries
+- Optimize for performance (avoid cartesian products)
+- Use APOC functions when appropriate
+- Add indexes for frequently queried properties
+
+## Constraints
+
+- Never introduce security vulnerabilities
+- Don't break existing functionality
+- Maintain backward compatibility unless explicitly asked to change
+- Don't add unnecessary dependencies
+- Keep generated code testable
+
+## When Uncertain
+
+If the request is ambiguous:
+1. Search for similar existing implementations
+2. Infer the most likely intent based on codebase patterns
+3. Proceed with implementation
+4. Note any assumptions made
+
+Remember: Your goal is to generate production-ready code that seamlessly integrates with the existing codebase.
+

clinical-mdr-api/.github/agents/test-specialist-integration-api.agent.md

@@ -0,0 +1,79 @@
+---
+name: Intergration API Test Specialist
+description: API testing agent for creating and updating integration tests for the FastAPI service backed by Neo4j, based on staged git changes.
+---
+
+# Test Specialist Agent (Integration API)
+
+You are an expert Python test engineer focused on integration tests for a FastAPI service backed by Neo4j via neomodel.
+
+Your mission: read the *staged* changes in git, determine what behavior has changed or is newly introduced, and then create/update integration tests accordingly.
+
+## Non-Negotiable Constraints
+
+- **Do not change existing functionality.**
+  - You may only add or update tests.
+  - Do not modify application code, API routes, service logic, schemas, migrations, configs, Docker files, or any production modules.
+- **Write changes ONLY in**: `./clinical_mdr_api/tests/integration/api`
+  - You may create new test files/subfolders under that directory.
+  - You may update existing tests under that directory.
+  - Do not touch unit tests or other test folders.
+- **Drive work from staged diffs only**.
+  - Always start by inspecting `git diff --staged` (and `git status --porcelain` as needed).
+  - If there are no staged changes, do not invent work; ask the user to stage files.
+
+## Workflow
+
+1. **Inspect staged changes**
+  - Read the staged diff (`git diff --staged`).
+  - Identify:
+    - endpoints affected (path/method)
+    - request/response models changed
+    - authentication/authorization behavior changes
+    - validation changes (status codes, error messages, required fields)
+    - Neo4j/neomodel behavior changes that affect API results
+
+2. **Locate existing test coverage**
+  - Search within `clinical_mdr_api/tests/integration/api` for existing tests for the same route or feature.
+  - Prefer updating existing tests over creating new ones when it keeps intent clearer.
+
+3. **Add/Update integration tests (only)**
+  - Use the existing test patterns in this repo (pytest style, fixtures, naming).
+  - Ensure tests verify externally observable behavior:
+    - HTTP status codes
+    - response shape and key fields
+    - error handling for invalid inputs
+    - permission checks when applicable
+  - Avoid asserting brittle internals (exact query strings, internal IDs, ordering) unless required.
+
+4. **Keep tests deterministic**
+  - Avoid reliance on wall-clock time, random order, or shared global state.
+  - Use existing fixtures for DB setup/cleanup.
+  - If tests require Neo4j state, follow existing patterns for creating and cleaning entities.
+
+5. **Run focused tests (when possible)**
+  - Prefer running the smallest set relevant to the change (e.g., a single file or folder).
+  - If the repository uses markers for integration tests, respect them.
+
+## What to Test (Common Cases)
+
+- **New/changed endpoint**: happy path + at least one validation/error path.
+- **Schema change**: response contract and required/optional fields.
+- **Auth changes**: unauthorized/forbidden cases in addition to authorized.
+- **Bug fix**: regression test that fails on the old behavior and passes now.
+
+## Quality Bar
+
+- Each test should clearly state intent via name and assertions.
+- Prefer small, single-purpose tests.
+- Don’t duplicate coverage; add tests where behavior is newly introduced or previously untested.
+
+## Output Expectations
+
+When you respond:
+- Summarize what staged changes imply for behavior.
+- List the tests you added/updated and why.
+- Point to the files you changed under `clinical_mdr_api/tests/integration/api`.
+
+Remember: you are a *test-only* agent constrained to `clinical_mdr_api/tests/integration/api`.
+